Re: Use the same passphrase for PGP and SSH keys and get prompted only once by gpg-agent

[Ben McGinnes]

On Tue, Feb 13, 2018 at 04:55:19PM +0100, Werner Koch wrote:
> On Tue, 13 Feb 2018 15:03, ambre...@gmail.com said:
> 
> > Thanks for the detailed answer.  But why not doing it for SSH then?
> 
> I like to see when an ssh key is used the first time.  Note that the
> maximum caching time for ssh keys can be configured independent from the
> caching time of other keys.

Probably wise.

> > Just because it's less common?  Would there be any way to configure this?
> 
> No, there is no way to configure an extra hack to also test a passphrase
> for an ssh key.

Wanna bet?

I thought of one way, but really is a hack and it's predicated on the
standard key access being invoked first.  If SSH always comes first
then it won't work.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Ben McGinnes]

On Sat, Feb 17, 2018 at 05:06:54PM -0600, helices wrote:
> I will probably never understand why wanting to run the most current
> version of gnupg on a plethora of servers is controversial.
> 
> Nevertheless, the two (2) greatest reasons are:
> 
>1. PCI DSS v3.2
>2. PCI DSS compliance audits

Ah, now *this* is a pertinent fact that would've helped at the
beginning of the thread and the fact that it wasn't is a clear
demonstration of a tangential point I made further along about getting
people to step back from their drilled in focus so we can identify the
actual needs.

Because these two lines explain *precisely* why you need something like
RHEL or CentOS (certified systems to go with the auditing) *and*
updated crypto.

> Being able to demonstrate that we are using the latest, greatest
> encryption available on every one of our hosts, simplifies that
> portion of the audit equation more than you probably believe.

That's funny ... I'll leave it alone since there have been gaps in my
posting recently.  In future, though, maybe double-check LinkedIn
before making assumptions about everyone here, or anyone.

Some of us have dealt with things a good deal more rigorously
scrutinised than mere PCI-DSS.

> Are there any other questions before I get a direct answer to my
> original subject question?

Not for RPM, not without compiling it yourself, but you said you
didn't want to do that.

As far as I'm aware there's nothing like FreeBSD's port system or pkg
system (or like MacPorts) in addition to rpm with any of the current
distros by default.  They all pick their preferred package manager and
that's their salient feature (along with the current "systemd vs
lol-no-never-in-hell" debate) and point of differentiation.

Although another part of this thread gave Werner an idea for an
addition to 2.2.5 to improve the static-vs-shared libs issue with
GnuPG and the rest of the system.  That might in future improve the
ability for package managers to have independent system libs and user
accessable libs and more recent versions to meet both user and system
requirements more readily.

Precompiled binaries are always going to be architecture dependent or
packed full of extra code to support a broader architecture.  Plus for
auditing purposes you are actually better off using a compiled version
using certified compilers and glibc (which RHEL brings to the
situation).  There's a lot of focus here on Debian and those
distributions it spawned, due to overlapping involvement for some team
members, but even with that hasn't resulted in "official Debian
packages" or whatever.

There are binaries for some system types for which prior releases were
sporadic (early OS X builds, non GPG4Win win32 executables, that sort
of thing), but nothing like you described and specific to a
distribution which is known to remain on much older versions of
everything and backport security fixes to those versions.

In which case, perhaps it is better to simply bite the bullet and
manage a local repo where everything therein meets those requirements.

If it does, I can think of one way to make it pay for itself and it
runs along the lines of subscriber only access to a repo explicitly
intended for PCI-DSS compliance, though it may require more frequent
audits of that part.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG

[Daniel Kahn Gillmor]

On Tue 2018-02-20 16:08:35 +0100, Werner Koch wrote:
> On Mon, 19 Feb 2018 19:45, d...@fifthhorseman.net said:
>
>> GnuPG is under active development, and it has never had a fully-featured
>> stable API (Application Programming Interface).  What i mean is, there
>> are some capabilities that are only available from the user interface
>> (UI), and are not in the stable API.  GnuPG's UI has been constantly
>
> You probably expected that I need to dissent: Modulo a few bugs there
> has always been a stable API in GnuPG and we have taken great caution to
> not break it.

We're not in disagreement, actually :) I explicitly said that what was
has been lacking was a "*fully-featured* stable API".  I didn't say that
the API was not stable.  But the UI has features that the API does not,
and this results in people using the UI as though it was an API, or
mucking about with the innards of the local storage.  As one example, I
know this because i've been through that when working on early versions
of monkeysphere; i was using bash around GnuPG and yeah, in a few cases
i ended up stuffing a pipeline of "commands" into a gpg invocation
because it was there and seemed to do roughly what i wanted. 

The GnuPG stable API is much more fully-featured today (thank you for
the --quick-* commands!), but that has not been the case historically.
And we're paying the cost for that with legacy applications that have
ossified around wrong assumptions about how to interact with GnuPG :/

> Granted some parts of the API are not easy to use but
> nevertheless, they are stable.  For example the --edit-key interactor
> requires the use a state machine to stay compatible with future versions
> of GnuPG.  This has been remarked over and over in the last ~20 years.

Sorry, but building a state machine in external code to model the
internal state of a tool is not a functional API that we can
realistically expect developers to use.  If a module has state, it needs
to express that state to the user and make the transitions clear and
functional, with comprehensible and easily-handlable error cases.  To
wit:

> Unfortunately some folks reject to read manuals, examples and
> description on proper use and just go ahead and do what seems to work.

Even the folks like me, who read manuals and examples and descriptions
of proper use will eventually just go ahead and do what seems to work :/
The goal of using someone else's code is to *relieve* yourself of
needing to know exactly how that code works.  I know that there are some
people that end up sending patches upstream for every project they
touch.  But most developers don't have time or energy for that, and they
need simple, clear interfaces.

This is why (for example) i've argued in the past for making the return
code for gpgv simple and closely aligned with the boolean tests what
people are likely to want (https://dev.gnupg.org/T1537#100523).  Not
everyone wants to write a parser for a text stream to find out if a
signature is valid.  Some folks just want to know whether a signature is
valid, and are happy to punt on the details.

And even if everyone *did* want to write a parser, how many different
parser implementations do you think would need to be created?  how many
of them would be bug-free?  checking a return code is much harder to get
wrong.

> Actually this is not just a gpg thing: I have seen too many scripts and
> programs which neglect to use LC_ALL=C and break as soon as they are
> running under a different locale.

very true.  it's quite difficult to write robust programs, even when
interfaces are simple and clear and don't have sneaky side-effects or
behavioral changes due to rarely-changed environment variables.  And
even if you test with LC_ALL=C, did you test with LC_ALL=C.UTF-8 ? :P

> To avoid such breakage but keeping friendly to the command line user,
> gpg provide a machine interface (--with-colons, --batch, --command-fd)
> to make automation easy.

yes, these are great things!  thank you for them!

> I can't count how often I wrote that the only defined way to access the
> content of keyrings are my means of the --export and --import commands.  

I know.  I can't count how many times i've said it either.  It's pretty
frustrating!  I think it's aggravated further by the fact that we don't
have a clear rule like "do not touch anything inside ~/.gnupg" -- those
kinds of rules end up riddled with caveats like "well, except for
sshcontrol and gpg.conf" or "oh, you want to do custom subkey
management? let me tell you how to poke around in private-keys-v1.d/" :/

> Please give examples.

did you look at the bug reports i already cited?  Those are definitely
examples of overly-brittle wrappers around GnuPG.  You might also be
interested in Request-Tracker's brittle bindings
(https://bugs.debian.org/832829), or pretty much anything in debian that
explicitly Depends: gnupg1 today.

I'd be game to cc you every time i hold a project's hand through some
tricky problem if you'd like.  

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Daniel Kahn Gillmor]

On Tue 2018-02-20 13:18:40 +0100, Dashamir Hoxha wrote:
> One solution to this situation may be to install the latest GnuPG
> in a Docker container, where it can have all the required libraries
> and dependencies that it needs, without disturbing the host OS.

I think this misses the point that it's not just *what does gnupg depend
on* but it's also *what depends on gnupg*.  The dependencies work in
both directions.

> Another solution may be to use a "snap", which is a kind of new
> software packaging invented by Ubuntu:

The basic idea behind "snap" and "flatpak" and other similar tools is
what many people call "bundling" or "vendoring" -- you ship the program
together with all its dependencies, regardless of what dependencies are
on the host system.  it's not a new idea at all, and is quite common on
many platforms, including in some flavors of cowboy web development.

As with docker containsers, this approach doesn't address the other
direction of the dependency graph.  In addition, all of these approaches
have maintenance costs and open questions about responsibility.  if
every app ships with its own bundled copy of libfoo, and a flaw is found
in libfoo, then it needs to be fixed.  can you be sure you've found and
fixed all copies?  Who is responsible for fixing each specific copy?  Do
those maintainers have enough time/attention/living expenses to make
sure vulerabilities and software flaws get patched in all of their
dependencies?  are they willing to re-ship the entire bundle/snap/docker
image for each dependency that needs an upgrade?

I recently heard bundling/vendoring/snaps/docker containers
characterized in the following way, which resonated with me:

Hm, maintaining a complex operating system is hard.  I know, we can
fix that by trying to maintain 100 complex operating systems
instead!

To be clear, i believe that there are contexts where bundling is
actually the right approach.  But it is not an obvious win to me in most
cases.

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Ben McGinnes]

On Mon, Feb 19, 2018 at 10:45:52AM -0800, Daniel Kahn Gillmor wrote:
> 
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.

True, but what it does have available still covers a *lot* of what
people do mainly want to access programmatically.  My trusty key
counter is now done that way (it takes a while to run, but that's due
to the size of the keybox, not due to GPGME).

> It also doesn't have bindings in many popular programming languages.

There is a cunning plan which may provide a bridge to at least in part
address that.

> When programmers in those language want to use GnuPG, their shortest
> path to "something that works" often involves shelling out to gpg,
> rather than binding to GPGME. :/

Yes

> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.

That would be brilliant, but it requires convincing developers to not
simply document their work, but to actually step back from their
focussed POV and abstract what they're intending to do so we can
determine what will actually be useful to procide all developers.
Otherwise we'll just end up with a bunch of feature requests specific
to the problem each developer happens to be working on at the time
they notify us.

If you can work out a way to get engineers to understand why that's
important ... you'll become very rich shortly thereafter.  ;)

> Perhaps GnuPG could also itself try to detect when it is being used
> programmatically in an unstable way and produce warnings?

Most of the worst of those examples are in bash, how're you going to
tell the difference between that and a user?

> Yet another complementary approach might be to aggressively police
> the ecosystem by finding other software that deends on GnuPG in any
> of the aforementioned brittle ways, and either ask those developers
> to stop using GnuPG entirely, or to provide them with stable,
> well-supported ways to do what they're looking to do.

And people accuse me of being combative!  Wow ... you're brave ...

Moreseriously, though, let's besure we've got an alternative method to
replace whatever their pet project's method is first.

Arguably gpgme-tool might already do that, but we'll see.

> I welcome discussion/suggestions on how we can improve this situation,
> and i *definitely* welcome help in doing the kind of
> ecosystem-perspective work necessary to make it easier to maintain an
> up-to-date branch of GnuPG.

I'm already laying the groundwork on the API side of things, as well
as working on doumentation.

> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Indeed.  I didn't check your buglist ... but I did recall that one of
the dependencies of GMIME is GPGME.  Pretty sure that'll affect a few
packages and libgcrypt & libgpg-error are a dependencies for lots things.

It's exactly this sort of thing which led to the popularity of
installing things the users wanted in /usr/local or /opt or wherever
specifically to prevent the end user use case adversely affecting the
system's use case.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Solaris 11 install libgpg-error/libgcrypt make install hangs

[Ben McGinnes]

On Fri, Feb 09, 2018 at 03:35:13PM +, Anna Kitces and Seth Fishman wrote:
> Hi
> 
> I ran ./configure, make, make check and entered make install over an
> hour ago

That seems a bit long.

> the make check was clean

Cool.

> If I hit ctrl-C, how do I proceed?
> 
> I am installing all the latest.
>
> Trying to get GnuPG installed and these are pre-reqs
> 
> I am not a developer so not sure the impact of cancelling a make
> install. do I need to do an uninstall?

Nope.

> Sorry but kind of at a loss on what to do.

Yeah, fair enough.  Since the make check was clean you can just try
running make install again (presumably you are doing that part as
root) and seeing if it completes.  If it does, great; if it doesn't
and just seems to hang then either post any reported errors here or
try moving on to the next library.  Eventually there will be a package
that has it as a dependency and if this install didn't actually work
you'll find out during the configure stage of the one to have it as a
dependency.

There's a reasonable chance it has actually installed, but done
something silly in reporting that fact during the installation.
Proceeding won't really hurt because the worst case scenario is just
going back to this point in the installation process and doing it
again.  It doesn't matter if binaries and libs are copied over during
a subsequent installation attempt since that's precisely how upgrades
occur anyway.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG

[Neal H. Walfield]

At Tue, 20 Feb 2018 16:08:35 +0100,
Werner Koch wrote:
> > Yet another complementary approach might be to aggressively police the
> > ecosystem by finding other software that deends on GnuPG in any of the
> > aforementioned brittle ways, and either ask those developers to stop
> 
> That is what our plan for the time after 2.2 was.  Unfortunately, this
> seems to be a boring job for some hackers and thus some of them opted to
> leave gnupg to work on cool new stuff instead.  Nevertheless, this is
> still high on my task list.

I'd rather not air dirty laundry, but I feel it necessary to correct
misinformation.  I did not leave g10code, because working on gpg was
"uncool".  I left because we (Werner and I) could not work well
together.  This is the same reason that Justus, Kai and Marcus left.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG

[Werner Koch]

On Mon, 19 Feb 2018 19:45, d...@fifthhorseman.net said:

> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).  What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.  GnuPG's UI has been constantly

You probably expected that I need to dissent: Modulo a few bugs there
has always been a stable API in GnuPG and we have taken great caution to
not break it.  Granted some parts of the API are not easy to use but
nevertheless, they are stable.  For example the --edit-key interactor
requires the use a state machine to stay compatible with future versions
of GnuPG.  This has been remarked over and over in the last ~20 years.
Unfortunately some folks reject to read manuals, examples and
description on proper use and just go ahead and do what seems to work.
Actually this is not just a gpg thing: I have seen too many scripts and
programs which neglect to use LC_ALL=C and break as soon as they are
running under a different locale.

To avoid such breakage but keeping friendly to the command line user,
gpg provide a machine interface (--with-colons, --batch, --command-fd)
to make automation easy.

> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.

Deprecated, okay.  But I am not aware of semantic changes except for
rare corner cases.

> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements

I can't count how often I wrote that the only defined way to access the
content of keyrings are my means of the --export and --import commands.  

Please give examples.

> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.

Right.  However, this is not due to changing APIs of GnuPG but due to
the wrong use of the API.  Much like we have seen that grep and sed
started to fail on localized systems.

And even today, we see hackers who are breaking working integration of
gpg by replacing the (correct) use of the machine interface by the
supposed easier to use human interface of gpg.  And then encountering
problems with newer versions of gpg.  :-(

> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.

Right.  That is a bad idea and that is why it took many years to get a
modern version in widespread use.

> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and

Library interfaces are as much abused as command line interfaces.  This
is not really the point.  A library may have the advantage that it
exposes only a smaller set of interfaces and thus lessens the risk of
wrong usage.

> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to

That is on purpose; see above.

> developers find useful.  Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce

Those tools won't notice these warnings because they hide away the
actual output of gpg. 

> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in any of the
> aforementioned brittle ways, and either ask those developers to stop

That is what our plan for the time after 2.2 was.  Unfortunately, this
seems to be a boring job for some hackers and thus some of them opted to
leave gnupg to work on cool new stuff instead.  Nevertheless, this is
still high on my task list.

> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Well said.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp5vybKgZDEZ.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG encryption and decryption takes excessive time.

[Ben McGinnes]

On Mon, Feb 19, 2018 at 01:30:06PM +, Green, Ian wrote:
> Hi
> Firstly, my knowledge of GPG is very weak and I am not a UNIX administrator, 
> so my access and knowledge are rather limited.
> 
> I have been asked to set up file encryption / decryption of files
> transferred between our SUN OS servers and two customer's servers.

What are the customers running?  More SunOSand/or Solaris or something
else?

> One customer is using a basic 2048 size key, the other a 3072 key.
> GPG has been installed and I have created my keys per the
> requirements of the clients and imported their keys without issues.
>
> I can encrypt files for them Ok and can decrypt the files they send me.
> 
> However, the time taken to encrypt and decrypt each file is colossal
> - between 6 (2048 key files) and 15 seconds (3072 key files) per
> file.

How big are the files and what kind of files (as in file type rather
than business use case)?

> I have set this up on two different local servers (same OS) and get
> the same results.
> 
> The server details are: SunOS ioponnet-kn-t1 5.10 Generic_142909-17
> sun4v sparc sun4v

It's actually SPARC?  Not UltraSPARC?  That hostname is hinting
towards a T1.  Is it really or is it something else?

Also, which filesystem(s) are you running?  ZFS or something ancient?

Are you trying to do this across NFS?  Are there also either a SAN or
NAS involved, if so, which (and did it come tith the Sun kit or was it
hooked in separately.

Well, may as well try the easy bit first ... run this as root:

iostat -En

Check the drives for collisions, if two of them are reporting massive
numbers of collisions then one is dead and the other is on the same
bus and is getting overloaded by the redirected traffic (which will
slow the rest of the array down).

That's the usual problem, but if it's not then we'll see.  Still
Solaris 10 has lots of nifty diagnostics tools to narrow things down
beyond that.

> Can anyone suggest anything to help reduce the time to something
> more viable?

Plenty, but I need to know what the system specs are before I can
determine what's actually feasible with that model.

The Solaris patch version indicates it's several years old as it is
and I'm guessing they're out of the warranty period.  Or maybe not, it
could just be that now that Oracle have fired all the old Sun
engineers there's no one there who can help ... and the fact that the
E25Ks and the M9000s are truly doomed is such a damned waste, but I
digress.

Don't be too disheartened if the model was produced prior to Oracle's
acquisition of Sun either, most of those systems were still well ahead
of any of what we called "x-boxes" (i.e. the X-series or anything with
an x86-64 architecture; IIRC they were all AMDs).  Besides, if it's
pre-2009, then I'll have at least a decent portion of the old SunSolve
handbook for the model in archive.  Yes, that is the massive trove of
Sun documentation that Oracle took offline in the first 3 months or
so; and no, it's not the whole thing (which was *huge*), just the
portable version).


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Kristian Fiskerstrand]

On 02/20/2018 01:18 PM, Dashamir Hoxha wrote:
> If anybody is willing to give a try to any of these solutions I would
> like to help.

I would be generally cautious for both approaches without proper support
in the surrounding infrastructure. In particular an upgrade to a
depending library would need to automatically cause a rebuild of the
container in the case of a security upgrade when such embedding happens,
which is generally a bad thing unless you have a large scale deployment
and defined QA processes for terminating and replacing containers with
new deployments regularly.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Manus manum lavat
One hand washes the other



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Dashamir Hoxha]

On Mon, Feb 19, 2018 at 7:45 PM, Daniel Kahn Gillmor 
wrote:

> On Sat 2018-02-17 17:06:54 -0600, helices wrote:
> > I will probably never understand why wanting to run the most current
> > version of gnupg on a plethora of servers is controversial.
>
> Here's one last try to explain the situation.
>
> GnuPG (and the libraries it depends on) are used by (aka "depended on
> by") other libraries and tools, both those integrated into the operating
> system itself, and those that might be externally installed.  Some of
> these dependencies are "brittle".
>

One solution to this situation may be to install the latest GnuPG
in a Docker container, where it can have all the required libraries
and dependencies that it needs, without disturbing the host OS.

But I am aware that this may present some challenges for  normal
usage and may not be suitable except for testing.

Another solution may be to use a "snap", which is a kind of new
software packaging invented by Ubuntu:
 - https://snapcraft.io/
 - https://docs.snapcraft.io/snaps/intro
The idea is that a software is shipped with all the dependencies,
so it does not matter in which OS it is installed, it will always work.

I don't know the details of snaps. Since it is a "containerized software
package" maybe it is not much different from the docker solution
above and maybe has the same challenges/problems.

If anybody is willing to give a try to any of these solutions I would like
to help.

Regards,
Dashamir
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why Operating Systems don't always upgrade GnuPG

[Peter Lebbing]

On 19/02/18 19:45, Daniel Kahn Gillmor wrote:
> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

You are right and I feel stupid for suggesting it is uncontroversial.
Hell, you'd think running Debian stretch/stable (with its 2.1.18) on a
plethora of servers would be uncontroversial, but even that isn't
totally free of controversy. There are people having problems with
adjusting their process to use GnuPG 2.1+.

I am very grateful for all the work you put in to not only fix programs
in Debian depending on /usr/bin/gpg2 being 2.0, but also fix programs
depending on /usr/bin/gpg being 1.4. Because even though
co-installability was considered while designing 2.1, in practice 1.4
and 2.1+ don't mix well.

Thank you.

If done with care and attention, there are still situations where
installing GnuPG 2.2 on what is the most recent version of CentOS/RHEL
is a good thing to do. You have to carefully consider which software
will be using GnuPG, though.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users