[Pki-devel] [PATCH] To fix 1358462 - pki pkcs12-cert-del shows a successfully deleted message when a wrong nickname is provided

[Endi Sukma Dewata]

Hi,

I pushed the patch to master (10.4) with some changes. Instead of 
exiting to the system it throws an exception so that the application can 
decide what to do with the error. I also revised the exception message 
and fixed the formatting. Thanks!

-- 
Endi S. Dewata

On 8/12/2016 6:24 AM, Geetika Kapoor wrote:
> Hello Endi ,
>
> Here is the fix with test cases that i tested.
>
> Thanks
> Geetika
>
> On 08/12/2016 08:50 AM, Geetika Kapoor wrote:
>> Yes Endi your right .. Fix should be more generic .. I will fix it in core method and will send for review.
>>
>> Thanks
>> Geetika
>> ----- Original Message -----
>> From: Endi Sukma Dewata <edewata at redhat.com>
>> To: Geetika Kapoor <gkapoor at redhat.com>, pki-devel at redhat.com
>> Sent: Thu, 11 Aug 2016 21:25:03 -0400 (EDT)
>> Subject: Re: [Pki-devel] [PATCH] To fix 1358462 - pki pkcs12-cert-del shows a successfully deleted message when a wrong nickname is provided
>>
>> On 8/11/2016 4:56 AM, Geetika Kapoor wrote:
>>> Hi,
>>>
>>> This patch fix BZ 1358462 - pki pkcs12-cert-del shows a successfully
>>> deleted message when a wrong nickname is provided.
>>> If we provide wrong cert nickname it gives "Certificate Nickname
>>> subsystemCert cert-topology-02-CA doesn't exist" and also if cert
>>> nickname doesn't exist it won't share the number of entries present.
>>> If cert nickname match then only it shows how many entries exist.
>>>
>>> Thanks
>>> Geetika
>> Hi Geetika,
>>
>> Similar to what I mentioned to Abhijeet, I added your patch to this
>> ticket to make sure it's not forgotten:
>> https://fedorahosted.org/pki/ticket/2414
>>
>> I looked at the patch briefly, I think instead of fixing it in
>> PKCS12CertRemoveCLI, it probably should be fixed in the
>> PKCS12.removeCertInfoByNickname(). Basically if the cert to be deleted
>> doesn't exist the method should throw an exception. The CLI then should
>> catch the exception and display the error. This way the error checking
>> will be done consistently regardless who calls the method.
>>
>> If you're going to revise the patch please attach it to this ticket.
>>
>> Thanks.
>>
>