GnuPG

GnuPG

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Hi All,


I was looking at GnuPG and it seemed very old to me. Then I realised it was on the Classic Branch 1.4. Reading about this branch, it is still getting security updates (last in 2018) but its purpose is said to be to support people who have archives of documents, messages, etc that are signed by old PGP keys that are no longer supported in the Modern Branch 2.x.. Hence 1.4 is required to be able to decrypt them.

Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys.

If yes, or there is some other reason that means IPFire should stay on 1.4 then I will leave GnuPG alone.

If no then I would have a go at updating GnuPG to the 2.2 Branch that is current.

I will wait to hear your feedback on this before doing anything.


Regards,

Adolf.

Re: GnuPG

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Hello Adolf,
hello development folks,

sorry for my tardy reply.

> Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys. 

(Assuming this was a question:) To my knowledge, we do not have key material in operation that would not
be supported by GnuPG 2.x - the "classic" branch simply is more lightweight than the 2.x branch.

The last time I looked at this, GnuPG 2.x required some flavour of the "pinentry" helper for entering
passphrases, and won't compile without. Since there is no manual interaction on a firewall, "pinentry"
is useless, but I was unable to work out how to omit it in GnuPG 2.x .

Things could have been changed, meanwhile. Perhaps this is now possible, so if you have some spare time
to look at this, go ahead. :-)

Thank you very much in advance for your efforts - and all your patches of the last weeks.

Thanks, and best regards,
Peter Müller

Re: GnuPG

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Hi Peter,

On 27/03/2021 21:11, Peter Müller wrote:
> Hello Adolf,
> hello development folks,
> 
> sorry for my tardy reply.
No problems. I know you have been and are very busy people.
> 
>> Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys.
> 
> (Assuming this was a question:) To my knowledge, we do not have key material in operation that would not
> be supported by GnuPG 2.x - the "classic" branch simply is more lightweight than the 2.x branch.
> 
> The last time I looked at this, GnuPG 2.x required some flavour of the "pinentry" helper for entering
> passphrases, and won't compile without. Since there is no manual interaction on a firewall, "pinentry"
> is useless, but I was unable to work out how to omit it in GnuPG 2.x .
Thanks for the heads up on this.
> 
> Things could have been changed, meanwhile. Perhaps this is now possible, so if you have some spare time
> to look at this, go ahead. :-)
I will give it a try. The worst that can happen is that I can't get it working and we stay with the status quo which is working currently.
> 
> Thank you very much in advance for your efforts - and all your patches of the last weeks.
> 
I am glad to help where I can.I know I can't help you with the real core stuff, my capabilities aren't sufficient but I can generally help with providing update patches on anything that I find has newer versions.

Regards,
Adolf

> Thanks, and best regards,
> Peter Müller
> 

Re: GnuPG

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Hello,

As far as I know we do not use any exotic functionality.

The main (and maybe even only) user is pakfire, if that works we are fine. If that breaks, we are a bit screwed :)

-Michael

> On 27 Mar 2021, at 21:39, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Peter,
> 
> On 27/03/2021 21:11, Peter Müller wrote:
>> Hello Adolf,
>> hello development folks,
>> sorry for my tardy reply.
> No problems. I know you have been and are very busy people.
>>> Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys.
>> (Assuming this was a question:) To my knowledge, we do not have key material in operation that would not
>> be supported by GnuPG 2.x - the "classic" branch simply is more lightweight than the 2.x branch.
>> The last time I looked at this, GnuPG 2.x required some flavour of the "pinentry" helper for entering
>> passphrases, and won't compile without. Since there is no manual interaction on a firewall, "pinentry"
>> is useless, but I was unable to work out how to omit it in GnuPG 2.x .
> Thanks for the heads up on this.
>> Things could have been changed, meanwhile. Perhaps this is now possible, so if you have some spare time
>> to look at this, go ahead. :-)
> I will give it a try. The worst that can happen is that I can't get it working and we stay with the status quo which is working currently.
>> Thank you very much in advance for your efforts - and all your patches of the last weeks.
> I am glad to help where I can.I know I can't help you with the real core stuff, my capabilities aren't sufficient but I can generally help with providing update patches on anything that I find has newer versions.
> 
> Regards,
> Adolf
> 
>> Thanks, and best regards,
>> Peter Müller

Re: GnuPG

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

Hi Michael,

On 29/03/2021 22:22, Michael Tremer wrote:
> Hello,
> 
> As far as I know we do not use any exotic functionality.
> 
> The main (and maybe even only) user is pakfire, if that works we are fine. If that breaks, we are a bit screwed :)
Understand. At the worst we just stay where we are on the 1.4 classic branch.
Based on the input from Peter I did some searching and may have found some command line options related to the pinentry aspect that disable it.

I will try to build and if successful, I will install the built iso and see how pakfire works for addon installs. If it works okay then I will provide a patch for wider review and testing. If it doesn't then I will leave things as they are for now.

Thanks and regards,
Adolf.
> 
> -Michael
> 
>> On 27 Mar 2021, at 21:39, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Peter,
>>
>> On 27/03/2021 21:11, Peter Müller wrote:
>>> Hello Adolf,
>>> hello development folks,
>>> sorry for my tardy reply.
>> No problems. I know you have been and are very busy people.
>>>> Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys.
>>> (Assuming this was a question:) To my knowledge, we do not have key material in operation that would not
>>> be supported by GnuPG 2.x - the "classic" branch simply is more lightweight than the 2.x branch.
>>> The last time I looked at this, GnuPG 2.x required some flavour of the "pinentry" helper for entering
>>> passphrases, and won't compile without. Since there is no manual interaction on a firewall, "pinentry"
>>> is useless, but I was unable to work out how to omit it in GnuPG 2.x .
>> Thanks for the heads up on this.
>>> Things could have been changed, meanwhile. Perhaps this is now possible, so if you have some spare time
>>> to look at this, go ahead. :-)
>> I will give it a try. The worst that can happen is that I can't get it working and we stay with the status quo which is working currently.
>>> Thank you very much in advance for your efforts - and all your patches of the last weeks.
>> I am glad to help where I can.I know I can't help you with the real core stuff, my capabilities aren't sufficient but I can generally help with providing update patches on anything that I find has newer versions.
>>
>> Regards,
>> Adolf
>>
>>> Thanks, and best regards,
>>> Peter Müller
> 

Re: GnuPG

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

Hi,

> On 29 Mar 2021, at 21:51, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 29/03/2021 22:22, Michael Tremer wrote:
>> Hello,
>> As far as I know we do not use any exotic functionality.
>> The main (and maybe even only) user is pakfire, if that works we are fine. If that breaks, we are a bit screwed :)
> Understand. At the worst we just stay where we are on the 1.4 classic branch.
> Based on the input from Peter I did some searching and may have found some command line options related to the pinentry aspect that disable it.

Pinentry will probably be required to be there as a build and runtime dependency, but we are not using it.

> I will try to build and if successful, I will install the built iso and see how pakfire works for addon installs. If it works okay then I will provide a patch for wider review and testing. If it doesn't then I will leave things as they are for now.

Importing the keys and validating the packages should not have changed. If it did, a couple of command line switch updates will do it. So we should be able to tackle this :)

-Michael

> Thanks and regards,
> Adolf.
>> -Michael
>>> On 27 Mar 2021, at 21:39, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> On 27/03/2021 21:11, Peter Müller wrote:
>>>> Hello Adolf,
>>>> hello development folks,
>>>> sorry for my tardy reply.
>>> No problems. I know you have been and are very busy people.
>>>>> Is IPFire using the 1.4 Branch because there is some historic requirement for the older insecure keys.
>>>> (Assuming this was a question:) To my knowledge, we do not have key material in operation that would not
>>>> be supported by GnuPG 2.x - the "classic" branch simply is more lightweight than the 2.x branch.
>>>> The last time I looked at this, GnuPG 2.x required some flavour of the "pinentry" helper for entering
>>>> passphrases, and won't compile without. Since there is no manual interaction on a firewall, "pinentry"
>>>> is useless, but I was unable to work out how to omit it in GnuPG 2.x .
>>> Thanks for the heads up on this.
>>>> Things could have been changed, meanwhile. Perhaps this is now possible, so if you have some spare time
>>>> to look at this, go ahead. :-)
>>> I will give it a try. The worst that can happen is that I can't get it working and we stay with the status quo which is working currently.
>>>> Thank you very much in advance for your efforts - and all your patches of the last weeks.
>>> I am glad to help where I can.I know I can't help you with the real core stuff, my capabilities aren't sufficient but I can generally help with providing update patches on anything that I find has newer versions.
>>> 
>>> Regards,
>>> Adolf
>>> 
>>>> Thanks, and best regards,
>>>> Peter Müller