GnuPG 2.4 has landed in Sid.
I am already happily using GnuPG with TPM support (from experimental)
for several months now without problems, including for signing
automated backups with a machine-bound key. This will probably be
available for everyone in Trixie.
Thanks to everyone involved for
On 2025-01-17 Frank Guthausen wrote:
> On Tue, 7 Jan 2025 19:01:51 +0100
> Andreas Metzler wrote:
> >
> > Afaik there is no /known/ blocker except for the
> > libgnupg-interface-perl test error #1088155.
> According to bug report[1] there are failed subtests in 2.4.6 but these
> are not specifi
On Tue, 7 Jan 2025 19:01:51 +0100
Andreas Metzler wrote:
>
> Afaik there is no /known/ blocker except for the
> libgnupg-interface-perl test error #1088155.
According to bug report[1] there are failed subtests in 2.4.6 but these
are not specified. What causes this failures and what needs to be d
On Tue, Jan 14, 2025 at 06:10:22PM +0100, Simon Josefsson wrote:
>
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like th
Marco d'Itri writes:
> On Jan 14, Simon Josefsson wrote:
>
>> Do you have earlier examples of Debian modifying upstream's desired wire
>> crypto-sensitive protocol in the way like what is being done for GnuPG?
>> Maybe there are some older OpenSSH or Ope
On Jan 14, Simon Josefsson wrote:
> Do you have earlier examples of Debian modifying upstream's desired wire
> crypto-sensitive protocol in the way like what is being done for GnuPG?
> Maybe there are some older OpenSSH or OpenSSL patches like that.
Like the Kerberos patch for Open
thout changing its name.
> We have been doing this since Debian exists, so I think that you will
> have to express a much more articulate argument than "I don't think it
> is a good idea".
Do you have earlier examples of Debian modifying upstream's desired wire
crypto-
Simon Joseffson wrote:
If the justification for those modifications are disagreement with
upstream about how GnuPG should behave with regard to the wire
protocol, it becomes even more clear to me that we are talking about a
fork.
The disagreements are not so much about which wire formats
s since Debian exists, so I think that you will
have to express a much more articulate argument than "I don't think it
is a good idea".
> And also please upload verbatim upstream GnuPG separately. This allows
> user choice.
Why don't YOU do it, if you really care s
. That's why I personally no longer install
>Debian for example, because I prefer a 100% free software OS. Right now
>user decision is crippled because users cannot conveniently get to the
>proper GnuPG package from Debian, and I believe that's bad for everyone;
>users, Debian, and
Thank you for clarifying a bit about who is behind FreePG!
Andrew Gallagher writes:
> Simon Joseffson mailto:si...@joseffson.org>> wrote:
>
>> It seems there is push from the anti-GnuPG people to promote a fork
>> called FreePG instead of real GnuPG, will you p
coherent ecosystem?
> However, GnuPG's reaction to start their own standard is not helping
> either.
I agree that it is not helping on a coherent ecosystem, but I'm also
having a bit hard time finding any other solution from the GnuPG side
for a way forward if they think than 3 dif
Simon Joseffson mailto:si...@joseffson.org>> wrote:
> It seems there is push from the anti-GnuPG people to promote a fork called
> FreePG instead of real GnuPG, will you package that?
>
> https://gitlab.com/freepg/gnupg
FreePG is not an anti-GnuPG project, if anything it’s tr
d let people decide what they want to use.
> >>
> >> Sometimes it is better to let other make decisions rather than to make
> >> decisions for others.
> >
> > I agree, but in this instance given the reliance we have upon GnuPG
> > throughout the Debian ecosy
as i can tell, a disaster for both OpenPGP and
> for the GnuPG project. The best outcome would be for GnuPG to be able
> to parse the updated OpenPGP standards (keys, certificates, signatures,
> encryption), and to limit itself to emitting data that can also be read
> by other
This appears silly from an engineering perspective, but there is a
specific motivation behind it: Proton (the mail company) wants this to
simplify the implementation of PGP with Browser APIs.
As you said, too many optional ciphers are bad for compatibility. Note
that the key preferences do not hel
On 2025-01-13, Daniel Kahn Gillmor wrote:
> The idea that the other members of the working group were "forcing the
> schism" doesn't line up with my experience. Werner decided to step away
> from the process of standardizing something in an open and interoperable
> way.
At some point, one might
Sune Vuorela wrote:
> Not only that, but some of these people were also in the
> standardization workgroup knowingly forcing the schism by wanting,
> what GnuPG upstream describes as, 'useless complexity' (my wording,
> not theirs).
Hi there! In addition to having he
On 2025-01-13 Simon Josefsson wrote:
> Jonathan McDowell writes:
[...]
> > I agree, but in this instance given the reliance we have upon GnuPG
> > throughout the Debian ecosystem I believe it's important we ensure that
> > the default configuration of what we ship
One of the prominently announced features of the 2.3/2.4 branches was
multi-smartcard support and support for TPM 2.0 key wrapping.
Regards
signature.asc
Description: This is a digitally signed message part
Things didn't work in GnuPG 2.2 but
>> was fixed years ago in 2.4.
>
> If you could identify the specific missing feature, i'd love to try to
> figure out what's going on there (with either 2.2 or 2.4). A bug report
> would be particularly useful. Thanks!
I found on
On Wed, 8 Jan 2025 at 23:08, Daniel Kahn Gillmor wrote:
>
> Thanks for this discussion, all--
>
> On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
> > I believe this would be good, I frequently run into GnuPG bugs in the
> > 2.2.x branch that was fixed year
On Mon 2025-01-13 10:53:30 +0100, Simon Josefsson wrote:
> I actually meant missing features. From my recollection it was features
> related to support for some subset of combinations of 25519, gpgsm,
> smartcards and the gpg/ssh agent. Things didn't work in GnuPG 2.2 but
> wa
On 2025-01-13, Simon Josefsson wrote:
> the way you want. This is even more true considering that the people
> who are patching GnuPG seems to be the same people who are working on
> replacing GnuPG with Seqoia.
Not only that, but some of these people were also in the standardization
ered help, but my impression has been that it not giving up on
>> the schism thing has been more important than getting Debian to ship
>> upstream code to users and let people decide what they want to use.
>>
>> Sometimes it is better to let other make decisions rather than to m
Since GnuPG 2.4 probably does not have any features removed (compared
to 2.2), is there anything other to do than patching the defaults for
new keys?
Debian has patches regarding GnuPG key defaults anyway, e.g. RSA key
size of 3072.
Regards
signature.asc
Description: This is a digitally signed
he schism thing has been more important than getting Debian to ship
> upstream code to users and let people decide what they want to use.
>
> Sometimes it is better to let other make decisions rather than to make
> decisions for others.
I agree, but in this instance given the reliance w
On Fri, 10 Jan 2025 19:33:01 +0100
Andreas Metzler wrote:
> On 2025-01-10 Frank Guthausen wrote:
> >
> > Is this still a problem with GnuPG 2.4.7? Can this be adjusted by
> > changing default configuration in the Debian package? Does it need
> > a code patch?
>
P implementations can't or won't
> support. GnuPG seems to be going their own way there, despite
> documented problems with some of their chosen cryptographic constructs
> like [v5-v3-signature-aliases] and [encryption-key-separation].
>
> [v5-v3-signature-aliases]
Daniel Kahn Gillmor writes:
> Thanks for this discussion, all--
>
> On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
>> I believe this would be good, I frequently run into GnuPG bugs in the
>> 2.2.x branch that was fixed years ago in 2.4
>
> Can you identify so
On Thu, Jan 09, 2025 at 07:55:36AM +0100, Stephan Verbücheln wrote:
> GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is
> generally not clear to me how the divergence from upstream is a reason
> to favor 2.2 over 2.4, except that patches have to be ported (once?).
&g
On 2025-01-10 Frank Guthausen wrote:
[...]
> I reconstructed the following timeline:
> Debian bullseye hard freeze[1]: 2021-03-12
> According to Upstream[2], GnuPG 2.4 birth: 2021-04-07 (maybe as devel)
Definitely -devel
https://lists.gnupg.org/pipermail/gnupg-announ
On Thu, 09 Jan 2025 18:29:02 -0500
Daniel Kahn Gillmor wrote:
> On Thu 2025-01-09 07:55:36 +0100, Stephan Verbücheln wrote:
> > GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It
> > is generally not clear to me how the divergence from upstream is a
> > rea
On Thu 2025-01-09 07:55:36 +0100, Stephan Verbücheln wrote:
> GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is
> generally not clear to me how the divergence from upstream is a reason
> to favor 2.2 over 2.4, except that patches have to be ported (once?).
sadly
GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is
generally not clear to me how the divergence from upstream is a reason
to favor 2.2 over 2.4, except that patches have to be ported (once?).
I also do not understand what is wrong/lacking with the already patched
versions in
Thanks for this discussion, all--
On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
> I believe this would be good, I frequently run into GnuPG bugs in the
> 2.2.x branch that was fixed years ago in 2.4
Can you identify some of those bugs? It would be good to be clear about
what
On 2025-01-08 Jonathan McDowell wrote:
> On Tue, Jan 07, 2025 at 07:01:51PM +0100, Andreas Metzler wrote:
[...]
>> Should we move to 2.4? 2.4 is not a LTS release and will also EOL in
>> trixie' soon (2026-06-30).
> I haven't been fully following the GnuPG situat
On Tue, Jan 07, 2025 at 07:01:51PM +0100, Andreas Metzler wrote:
> On 2025-01-07 Simon Josefsson wrote:
> [...]
>
> > I believe this would be good, I frequently run into GnuPG bugs in the
> > 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
> >
Andreas Metzler writes:
> On 2025-01-07 Simon Josefsson wrote:
> [...]
>
>> I believe this would be good, I frequently run into GnuPG bugs in the
>> 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
>> Debian because others moved on to 2.4.
Current Ubuntu 24.04 LTS also uses GnuPG 2.4 and probably has a similar
set of patches.
Regards
signature.asc
Description: This is a digitally signed message part
On 2025-01-07 Simon Josefsson wrote:
[...]
> I believe this would be good, I frequently run into GnuPG bugs in the
> 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
> Debian because others moved on to 2.4.x. Andreas, can you give a
> current status of pendin
Frank Guthausen writes:
> On Sat, 04 Jan 2025 08:42:10 +
> Stephan Verbücheln wrote:
>
>> Please note that GnuPG 2.2 is also end of life now.
>>
>> https://gnupg.org/download/index.html
>
> GnuPG 2.4.7 is in experimental[1] but neither yet in sid[2] or
On Sat, 04 Jan 2025 08:42:10 +
Stephan Verbücheln wrote:
> Please note that GnuPG 2.2 is also end of life now.
>
> https://gnupg.org/download/index.html
GnuPG 2.4.7 is in experimental[1] but neither yet in sid[2] or trixie[3]
(where it is version 2.2.45-2 in both repositories). T
Please note that GnuPG 2.2 is also end of life now.
https://gnupg.org/download/index.html
Regards
signature.asc
Description: This is a digitally signed message part
On Mon, Dec 23, 2024 at 01:57:42PM +0100, Guillem Jover wrote:
> Hi!
>
> On Mon, 2024-12-23 at 13:20:39 +0100, Chris Hofstaedtler wrote:
> > * Julian Andres Klode [241223 12:49]:
> > > Something still pulls in gpgv there
> > > which is unfortunate, we lack a 5MB savings.
>
> I think that would b
Hi!
On Mon, 2024-12-23 at 13:20:39 +0100, Chris Hofstaedtler wrote:
> * Julian Andres Klode [241223 12:49]:
> > Something still pulls in gpgv there
> > which is unfortunate, we lack a 5MB savings.
I think that would be gpgv being Priority: important, which makes
debootstrap and friends pull it i
* Julian Andres Klode [241223 12:49]:
> Something still pulls in gpgv there
> which is unfortunate, we lack a 5MB savings.
dpkg-dev Depends: gpgv | sq | ...
That seems odd. Maybe it wants gpgv | sqv | ...
instead?
If its not dpkg-dev, I don't see whats pulling gpgv.
Chris
On Mon, Dec 23, 2024 at 12:48:50PM +0100, Julian Andres Klode wrote:
> i.e. we see a 9MB saving for essential+apt, and a 4MB saving
> for a default mmdebstrap.
very nice!
> Something still pulls in gpgv there
> which is unfortunate, we lack a 5MB savings.
>
> More savings can be achieved by bui
gt; > The sqv binary is about 2MB large when optimized for size,
> > and provides good feedback when a key cannot be verified.
>
> The Sequoia sqv backend is now the default backend in unstable
> for architectures that have it (all release architectures, most
> ports).
>
e architectures,
> and `Depends: gpgv` for other (ports) architectures.
>
> The sqv binary is about 2MB large when optimized for size,
> and provides good feedback when a key cannot be verified.
The Sequoia sqv backend is now the default backend in unstable
for architectures that h
On Tue, Dec 03, 2024 at 04:34:52PM +0100, Julian Andres Klode wrote:
> On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
> > I've just finished more or less, adjusting the APT test suite
> > to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> > tomorrow. This ensures full
On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
>
> After that migrat
On Fri, Nov 22, 2024 at 01:53:11PM +0100, Julian Andres Klode wrote:
> We currently see a size increase of 8% (9MB uncompressed, 4MB gzipped) in an
> essential + apt bootstrap:
^^ that's trixie, in sid they're a bit smaller now and will probably soon
shrink further:
user@debian-work:/tmp $ schroo
I tried to find a blocking bug before my question on debian-devel, but
I could not find any bug which justifies the delay.
Note that Ubuntu 24.04 LTS also already uses GnuPG 2.4.x, so I do not
expect a problem with the Debian tooling base like dpkg and apt.
Regards
signature.asc
Description
On Mon, 25 Nov 2024 08:20:43 - (UTC)
Sune Vuorela wrote:
> On 2024-11-22, Frank Guthausen wrote:
> >
> > Which kind of default incompatibility is implemented in GnuPG 2.4?
>
> [...]
>
> LWN did an article in december about it.
Do you mean the schism article[
On 2024-11-22, Frank Guthausen wrote:
>> 1. The GnuPG upstream forked the OpenPGP standard into his own
>>thing called LibrePGP, and GnuPG 2.4 implements that new thing
>>and is by default incompatible with other OpenPGP implementations.
>
> Which kind of de
On Fri, 2024-11-22 at 18:00 +0100, Jonas Smedegaard wrote:
> Quoting Julian Andres Klode (2024-11-22 17:36:17)
> > On Fri, Nov 22, 2024 at 04:14:59PM +, Sune Vuorela wrote:
> > > On 2024-11-21, Julian Andres Klode wrote:
> > > > As for ports without gpgv-sq, this does not affect them,
> > > >
Quoting Chris Hofstaedtler (2024-11-23 04:16:29)
> * Jonas Smedegaard [241122 18:01]:
> > > All release architectures support Rust. We should not accept
> > > release architectures without Rust support.
> > >
> > > A minor set of ports architectures does not have Rust support
> > > yet.
> >
> >
On Fri, Nov 22, 2024 at 06:25:58PM +0100, Julian Andres Klode wrote:
> If you want to learn more about Sequoia and the Chameleon
> in particular, watch Holger's talk at this year's DebConf:
> https://debconf24.debconf.org/talks/16-chameleon-the-easy-way-to-try-out-sequoia-openpgp-written-in-rust/
* Jonas Smedegaard [241122 18:01]:
> > All release architectures support Rust. We should not accept
> > release architectures without Rust support.
> >
> > A minor set of ports architectures does not have Rust support
> > yet.
>
> Rust is unsupported on i386 and patched to silently assume i686
On Fri, Nov 22, 2024 at 01:53:11PM +0100, Julian Andres Klode wrote:
> On Thu, Nov 21, 2024 at 11:52:38PM +0100, Marco d'Itri wrote:
> > On Nov 21, Julian Andres Klode wrote:
> >
> > > I've just finished more or less, adjusting the APT test suite
> > > to test gpgv-sq. I plan to upload APT that t
> 1. The GnuPG upstream forked the OpenPGP standard into his own
>thing called LibrePGP, and GnuPG 2.4 implements that new thing
>and is by default incompatible with other OpenPGP implementations.
Which kind of default incompatibility is implemented in GnuPG 2.4?
kind regards
Frank
On Nov 22, Julian Andres Klode wrote:
> That's correct due to some overlinking in the Rust toolchain,
> there needs to be some more crate splitting to make it smaller.
Do you have reasons to believe that this is going to happen in time for
the next release?
The size increase is not trivial. :-(
On Thu, Nov 21, 2024 at 09:16:20PM +0100, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
2.9.14 in unstable co
Quoting Julian Andres Klode (2024-11-22 17:36:17)
> On Fri, Nov 22, 2024 at 04:14:59PM +, Sune Vuorela wrote:
> > On 2024-11-21, Julian Andres Klode wrote:
> > > As for ports without gpgv-sq, this does not affect them,
> > > they can be served by the gpgv alternative. Once a gpgv-sq
> > > is a
On Fri, Nov 22, 2024 at 04:14:59PM +, Sune Vuorela wrote:
> On 2024-11-21, Julian Andres Klode wrote:
> > As for ports without gpgv-sq, this does not affect them,
> > they can be served by the gpgv alternative. Once a gpgv-sq
> > is available, it's important to note that no migration happens
>
On 2024-11-21, Julian Andres Klode wrote:
> As for ports without gpgv-sq, this does not affect them,
> they can be served by the gpgv alternative. Once a gpgv-sq
> is available, it's important to note that no migration happens
To me it looks like we will sligthly grow the base system and have
dif
ormed I did not include the reasons and it's become
clear not everyone already knows the background here:
1. The GnuPG upstream forked the OpenPGP standard into his own
thing called LibrePGP, and GnuPG 2.4 implements that new thing
and is by default incompatible with other OpenPGP implement
On Thu, Nov 21, 2024 at 11:52:38PM +0100, Marco d'Itri wrote:
> On Nov 21, Julian Andres Klode wrote:
>
> > I've just finished more or less, adjusting the APT test suite
> > to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> > tomorrow. This ensures full compatibility between apt and
> >
On Thu, Nov 21, 2024 at 06:25:11PM -0700, Antonio Russo wrote:
> On 11/21/24 15:19, Iustin Pop wrote:
> > I'm not happy with the heavyness that one gets via gpg just for
> > verifying signatures, so I'd be all for a lighter-weight solution.
>
> gpgv is lighter weight than gpgv-sq. Surprisingly, i
On Fri, Nov 22, 2024 at 11:55:10AM +0100, Andreas Metzler wrote:
> On 2024-11-21 Julian Andres Klode wrote:
> [...]
> >An optimal mechanism would instea
> [...]
>
> Something seems to be missing here.
>
> cu Andreas
Apologies, I started that thought and didn't quite finish it
and forgot it
On 2024-11-21 Julian Andres Klode wrote:
[...]
>An optimal mechanism would instea
[...]
Something seems to be missing here.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
On 11/21/24 15:19, Iustin Pop wrote:
I'm not happy with the heavyness that one gets via gpg just for
verifying signatures, so I'd be all for a lighter-weight solution.
gpgv is lighter weight than gpgv-sq. Surprisingly, it's not just
the rustc-static-links-everything problem, since gpgv-static
On Fri, Nov 22, 2024 at 06:46:10AM +0900, Simon Richter wrote:
> Because there is no coordination between gpgv and gpgv-sq packages,
that's not entirely true.
> and
> dependent packages should have no reason to care. gpgv-sq unilaterally
> claims compatibility, and if something breaks as a resul
On Nov 21, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
OK, but why?
Did you make an analysis of how much
verifying signatures, so I'd be all for a lighter-weight solution.
I found https://lwn.net/Articles/830902/ which explains what Sequoia is,
but in Debian, is there a bigger plan for GnuPG -> Sequoia, or just
piecemeal adoption?
thanks!
iustin
Hi,
On 11/22/24 05:49, Gioele Barabucci wrote:
Unrelated to the apt proposal, how come dpkg-divert is being used here
by gpgv-from-sq instead of using the what-is-python/python-is-pythonX
approach of just shipping a symlink?
Because there is no coordination between gpgv and gpgv-sq packages,
On 21/11/24 21:16, Julian Andres Klode wrote:
1) The Depends will install gpgv-from-sq on new systems. The
gpgv-from-sq package diverts /usr/bin/gpgv to gpgv-g10code
and Provides gpgv, installing a symlink to gpgv-sq.
Unrelated to the apt proposal, how come dpkg-divert is being used her
alled.
This means existing systems will have two gpgv implementations:
- /usr/bin/gpgv from GnuPG
- /usr/bin/gpgv-sq from Sequioa
This is not necessarily the best outcome. We could change
it to gpgv-from-sq as well, such that systems remain with
a single /usr/bin/gpgv. I
Il 24/09/2024 14:43, Stephan Verbücheln ha scritto:
Hello everyone
Debian Trixie and Sid still have GnuPG 2.2.x. GnuPG 2.4.5 is available
in Experimental.
GnuPG 2.4.0 was released on December 20, 2022. The 2.4.x series has
various useful new features such as TPM support.
Is it realistic to
Hello everyone
Debian Trixie and Sid still have GnuPG 2.2.x. GnuPG 2.4.5 is available
in Experimental.
GnuPG 2.4.0 was released on December 20, 2022. The 2.4.x series has
various useful new features such as TPM support.
Is it realistic to get GnuPG 2.4 into Trixie before the freeze?
What is
Package: wnpp
Severity: ITP
X-Debbugs-CC: debian-devel@lists.debian.org
Greetings.
I was wondering if it would be possible to start maintaining the
devuan-keyring package on salsa, and have it being built upstream in
Debian?
This way it would be possible to unify our efforts in debootstrap
maint
Package: wnpp
Severity: ITP
X-Debbugs-CC: debian-devel@lists.debian.org
Greetings.
I was wondering if it would be possible to start maintaining the
devuan-keyring package on salsa, and have it being built upstream in
Debian?
This way it would be possible to unify our efforts in debootstrap
maint
Programming Lang: Makefile
Description : GnuPG keys of the Deepin archive
The Deepin project digitally signs its Release files. This package
contains the archive keys used for that.
.
I intend to co-maintain this package inside the pkg-deepin group.
On Fri, 14 Oct 2016 21:47, d...@fifthhorseman.net said:
>> In a new temp directory do:
>>
>> GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
>>
>> Or whatever you want to run under gpg-agent's control. This has been
>> there for ages.
>
> fwiw, this doesn't work (and actually returns an error) if
On Tue 2016-10-18 07:44:43 -0400, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669:
> Beware of leftover gpg-agent processes"):
>> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
>> > 1. gnupg1-compatible authorisa
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669:
Beware of leftover gpg-agent processes"):
> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> > 1. gnupg1-compatible authorisation lifetime:
>
> I believe this is a deliberate change in se
On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> 1. gnupg1-compatible authorisation lifetime:
I believe this is a deliberate change in semantics from the upstream
GnuPG project. In particular, authorization for the use of secret key
material is now the responsibility of the gpg-ag
perty.
(It's valuable even, or particularly, if none of the software invoking
gpg is malicious: because software can do unexpected things for other
reasons than malice.)
There should be a way for command line users (including users of
programs which themselves call gnupg) to have the same aut
On Sat, 15 Oct 2016, Mechtilde wrote:
> There is gpg version 2.1.15-4.
> Unter Jessie all things are fine with gpg 1.4.18
>
> Unter Stretch I have no access to my private key and the public keyring.
> I only see the keys which incomes with the mails after the update
>
> What happens? The files of
Hello,
since tha update on thursday I can't use GPG on Stretch.
There is gpg version 2.1.15-4.
Unter Jessie all things are fine with gpg 1.4.18
Unter Stretch I have no access to my private key and the public keyring.
I only see the keys which incomes with the mails after the update
What happen
eems likely to introduce new problems, and it isn't a change
> i'm up for either writing myself or supporting as a divergence from
> GnuPG upstream.
>
> The simple fix (cleaning up the test suite by eithe deleting the
> temporary GNUPGHOME directory or by invoking "gpgco
On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:
> authorisations, if the user types in a passphrase) have a lifetime
> limited by that of the gpg process which started the agent.
In a new temp directory do:
GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
Or whatever you want to
On Fri 2016-10-14 15:18:40 -0400, Werner Koch wrote:
> On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:
>
>> authorisations, if the user types in a passphrase) have a lifetime
>> limited by that of the gpg process which started the agent.
>
> In a new temp directory do:
>
> GNUPGHO
t; limited by that of the gpg process which started the agent.
fwiw, i'm not the person who needs persuading. Ian's proposal is rather
complex, seems likely to introduce new problems, and it isn't a change
i'm up for either writing myself or supporting as a divergence from
GnuPG
Ian Jackson writes ("Beware of leftover gpg-agent processes (was: Re: Changes
for GnuPG in debian)"):
> Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
> Changes for GnuPG in debian)"):
>
> > Quoting Daniel Kahn Gillmor (2016-08
On Sat, Aug 06, 2016 at 12:56:58PM -0400, Daniel Kahn Gillmor wrote:
> ouch! please do file this as a distinct bug report, it's something i
> haven't run into myself and i'd like to track it down.
Done, that's #833596.
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . .
On Sat 2016-08-06 06:32:39 -0400, Stefano Zacchiroli wrote:
>> >> systemctl --user enable gpg-agent
>> >> systemctl --user enable dirmngr
>
> OTOH, doing this inhibited a proper start of my GNOME session at next
> login: only Nautilus started (I can tell because I've it handle my
> desktop icon
; passphrase caching and smartcard management are useful features.
>
> I noticed after upgrading gnupg to experimental and monkeysphere to
> unstable, monkeysphere now has gpg-agent processes running as root:
>
> $ pgrep -a gpg | grep -i monk
> 27043 gpg-agent --homedir /var/lib/monkeys
On Sat, 6 Aug 2016 08:24, p...@debian.org said:
> BTW, does this make parcimonie obsolete? I noticed that dirmngr
We plan to add similar fucntionality to dirmngr but that has not yet
been done and I am not sure whether we will have it for 2.2.
Shalom-Salam,
Werner
--
Die Gedanken sind fr
1 - 100 of 290 matches
Mail list logo
