Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Questionable dependencies

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Vlad Glagolev <stealth AT tiberian.ru>
  • To: Source Mage Discussion <sm-discuss AT lists.ibiblio.org>
  • Subject: [SM-Discuss] Questionable dependencies
  • Date: Mon, 6 May 2019 10:52:00 -0700

Hey everyone,

As we get closer to new stable grimoire and new chroot images, the
dependency problem becomes more and more important. I'll touch only one
example here, but it basically applies to anything and everything when
we introduce changes like that.

Recently we deprecated gnupg 1.4, without taking care of the successor's
proper integration.

We should not forget gnupg is an essential component of the basesystem,
which means it's a part of the minimal image every installation starts
from. According to our last release [0], it contains 118 spells, and
I'd like to keep that list as small as possible. And with time it
should become smaller, not bigger, or at least have spells smaller in
terms of file size when possible. And of course it shouldn't contain
extra spells unless absolutely necessary for correct installation.

Flexibility that we have is what makes us different from many Linux
distros, but most and foremost it's important for our users.

Why minimum number of spells is preferred?:

- less components lead to simplicity, which in turn reduces complexity
while maintaining or upgrading the system, which is important for
developers as it is for regular users
- better flexibility: you're never locked out of something specific, as
you don't have many dependencies enforced for you for no reason
- smaller images are good for containers: containers are supposed to be
small blocks containerized clusters are built from: this allows us to
expand into Docker/LXC/Kubernetes/etc. lands and get some better
recognition cloud-wise [1]

Our recent decision [2] by forcing gnupg-2 as the only gpg
implementation was a bit harsh. Gentoo and OpenBSD didn't deprecate
gnupg 1.4, so I don't see any real reason why we should.

I wouldn't have a problem with gnupg2 if our spell didn't force gnutls,
which I'm not a big fan of [3]. And since there's more than one SSL/TLS
implementation library available, I'd like to keep it this way: allow
the user to choose. Just because many spells have optional dependencies
doesn't mean we should turn them all on and provide the final build of
the supposed-to-be-minimal image as a giant monolith, which makes life
for the end-user harder, not easier.

So this is what I think we should do:

1. Rewrite gnupg-2.2 spell so it allows compilation without gnutls and
other optional dependencies
2. Re-introduce gnupg spell and make it default, so it could be used in
the basesystem again
3. For portability reasons, where super-new algorithms are required use
hashes for source verification instead of GPG signatures: from 8551
spells in test grimoire only 23% rely on GPG signatures; the rest are
hash-based. One case where we were able to detect rollback to standard
algorithms is lzip, which can be verified with gnupg 1.4 again.

[0] https://sourcemage.org/Grimoire/stable/0.62
[1] https://github.com/docker-library/docs/pull/1433
[2] https://lists.ibiblio.org/sympa/arc/sm-discuss/2019-January/022371.html
[3] http://www.openldap.org/lists/openldap-devel/200802/msg00072.html

--
Vlad Glagolev <stealth AT tiberian.ru>

Attachment: pgpSX1Gstzwbm.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page