-----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----- _______________________________________________ Exherbo-dev mailing list Exherbo-dev@lists.exherbo.org http://lists.exherbo.org/mailman/listinfo/exherbo-dev
