Re: Updated GnuPG::Interface
On Tue, 2020-07-21 at 19:29 +0200, gregor herrmann wrote:
> On Tue, 21 Jul 2020 19:02:12 +1200, Andrew Ruthven wrote:
>
> > I've pushed a commit to libgnupg-interface-perl which resolves this
> > behaviour. We also now test libgnupg-interface-perl against both
> > versions of GnuPG.
> >
> > If someone could please review and (hopefully) upload the package,
> > that'd be much appreciated.
>
> Looks good to me in general.
>
> Some thoughts:
>
> - Does this also fix #964878?
Sadly no it doesn't. Bug #964878 is caused because monkeysphere-
validation-agent uses -T. GnuPG::Interface tries to use $ENV{PATH} -
which hasn't been untainted - to find gpg.
We have two options here. Either
patch /usr/share/perl5/Crypt/Monkeysphere/MSVA.pm in msva-perl to use
the full path to /usr/bin/gpg when GnuPG::Interface. Or we modify
GnuPG::Interface to use the full path instead of just running "gpg".
I'm leaning towards the later as otherwise we'll be playing whack-a-
mole for any other Perl programs that use Taint. Thoughts?
I'm happy to prepare that patch.
> - Could you forward the relevant patches upstream (to the CPAN RT
> issue)? Then we can wait a bit and see if there are reactions
> before uploading.
I already have. ;) No response from upstream for the first one which I
uploaded 5 days ago.
Fix for RT4 breakage: https://rt.cpan.org/Ticket/Display.html?id=133021
Fix for below warning: https://rt.cpan.org/Ticket/Display.html?d=133039
> - The tests throw some warnings:
>
> Can't exec "gnupg": No such file or directory at /build/libgnupg-
> interface-perl-1.00/blib/lib/GnuPG/Interface.pm line 343.
> Use of uninitialized value $a in split at /build/libgnupg-interface-
> perl-1.00/blib/lib/GnuPG/Interface.pm line 829, <GEN5> line 1.
> Use of uninitialized value $a in split at /build/libgnupg-interface-
> perl-1.00/blib/lib/GnuPG/Interface.pm line 829, <GEN5> line 1.
>
> (So the same for gpg2 and gpg1). Is this expected/harmless/…?
It is harmless, but I agree it is off putting. I have added a patch
which causes these warnings to be suppressed.
> - Not sure if CALL is the nicest possible name for the env var but
> that's bikeshedding territory :)
I am open to suggestions, but since it is the string to be passed in to
the call parameter, it seemed reasonable to me.
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
andrew@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
Reply to: