[Exherbo-dev] Yet another checksum proposal

Kylie McClain somasis at exherbo.org
Thu Jul 23 09:55:54 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/23/2015 05:12 AM, Niels Ole Salscheider wrote:
> Hi,
> 
> this sounds like a proposal that could be implemented quickly. It
> might only protect against broken downloads and upstream changing
> files but I would be glad if at least this annoying problem was
> solved.
> 
> Would this include unofficial repositories?

Yes, it would. Unofficial repository distfiles fetching was enabled on
distfiles.e.o a little while ago.

(that reminds me, maybe I should post the list of packages with bad
DOWNLOADS that the mirror daemon keeps spamming me with every day and
get others to do my work for me...)

> I thought a bit more about this problem after my last mail to the
> list and I think that another alternative would be to let paludis
> handle this: Imagine someone bumps a package with "git mv". He or
> she will still test the change locally (we all do, don't we?) and
> therefore use paludis to build it. Paludis would see that there is
> no checksum stored for (some of) the distfiles. It could then offer
> to add it to some defined file inside the repository, git commit
> the change (or amend the last commit) and push it to the local
> repository from which it synced before.

The concern I have there is that we get into the messy part of dealing
with automating SCM changes, which would result in making Paludis have
features which only work with git, or having to handle this for each SCM
repository that we support in Paludis. We only use git for our
repositories and unofficial repositories so far, but if we're going to
do something it really should be consistent when possible.

In addition this means doing things that add an extra step to the
workflow. Even if it's automated, it's still one we could do without...

> This would make the diff a bit more ugly since a checksum is added,
> but if that's all... The advantage compared to your proposal would
> be that it works for files that have not (yet) been fetched by the
> mirror.

That's possible but I personally think that dealing with things not yet
fetched by the mirror are low-priority; the mirror runs at the first
minute of every day. If some package is important enough to need a
checksum before the day is over, then I would think the small amount of
people updating in the amount of time between the package's bump and the
sum generation running wouldn't have benefited from a checksum being
there anyway.

In fact, (and I get the feeling you didn't really even mean it as this,
just thinking out-loud) this isn't really even so much of a security
feature as it is just integrity verification and protecting against
corrupted downloads. I remember a while back Ciaran getting into an
argument with someone on IRC about insisting checksums are a security
feature, the more I think about it the more I think he's right in
insisting that checksums are a pretty crap security feature if they are
at all.

Especially one where the single point of failure is a distfiles server.

> 
> Ole

(@ole, sorry for the duplicate email, @e.o email has been giving me
trouble and I had some trouble getting this sent to the list correctly
the first time.)

- -- 
Kylie McClain, Exherbo Linux developer and Musician
https://somasis.com - https://github.com/Somasis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVsLopAAoJEGd7orvXlNqp0pgQAM612sa2UGzPoZMqZAIndvMB
HpOzBAJXQectSVHgR3Add/3o3p4cTqNrArmRapsrTJzNEVF4M9/Frji5Y6N0bvr7
74rtIbK4BcURO/EEol059xIi3JxiZ/s1rD8qvGx5SygyU4FcHeiCgXJD6hW75PvD
Aa87xALjIP1IuskhteF/sMHfvfUAD0k0cmGnYIXk57y4o0YqANhag3ZG9CbkqBfu
bGJXvBzq9Ms9ixqZK09GQLG6t3S8r89D+6opKIdJMFPDVrZzmsn0NpNpH2DqcTLQ
Wj+3ZcTlzNSBBUUo6LNYDs+c5VCbDfXbQvYEYX2O9qq9OcTDayzto2fPzDPcl8DH
diOp+ezWY/HmfMYVA+ARrKinZaHhRLaXtN54aWJcqC9k6i8sdnNKXVkW2SDUfx/V
uqXKFlOxehqJ27LnFOuNP9lkanaH9MBtEYrx0dxKGNvz+QX05hRvRYbYHXHoxdl2
LUj4oy9/QulE0y1PBZONJQR41guWjtx8BXcNzg78NU5RxWzIkq+bbOuL+ZbEzhxb
iqsgwYw9ot5/bMspmPjeKdttUv5fRFRQUCv029neoqB2E1hgvbIbDesbmLEvChte
02vEepUrnyj+2lky3HTbbEDeJ8bab4GKMY3vYXcv1tsXpE2rtGjAIQvEa3fIp6JE
R5REzzkkuVPETJrt2Yez
=cren
-----END PGP SIGNATURE-----



More information about the Exherbo-dev mailing list