Filesize in Portfiles (was Re: [76684] trunk/dports/sysutils/rpm/Portfile)

[Jeff Johnson]

On Mar 8, 2011, at 2:53 PM, Jeff Johnson wrote:

> 
> On Mar 8, 2011, at 2:48 PM, Jordan K. Hubbard wrote:
>> 
>> A fine idea.  You can revisit this when MacPorts decides to make upstream maintainers start signing their distfiles. ;-)
>> 
> 
> Planned or snarky comment? Its not a bad idea (even if it would take years ...)
> 

I should expand on my comment (lest I get accused of snarkiness ;-)

MacPorts (and *BSD ports) usually have a "fetch" method with digests
that are carried through a separate "channel" like in Portfiles.

But in order to ensure referential integrity as well as to
provide a mirror of last resort, all the build elements from
"upstream" are often mirrored.

Because of the existence of all the tarballs somewhere, the next logical
step for stronger integrity checks would be to turn that into a
service  like trusted time stamps secured by a CA (there's an RFC for that ;-)
but for elements commonly distributed for FL/OSS software.

All I'm really saying is to take these three items:
	date of download
	URL downloaded from
	digest(s) of the element
	size and mtime and whatever else floats your boat
and secure the bundle with any old signature method you choose,
OpenPGP, X.509, whatever.

There's way too much time spent with last century methods of
ensuring reliable downloads, like MD5 and a digest check
post-fetch to somehow ensure integrity or trust.

MacPorts (and its "mirror-of-last-resort") could provide
that service for upstream tarballs withoiut a great deal of pain.

I know I'd instantly be trying to use that service in RPM ...
... anything that's easier to implement but still sufficiently
"trustworthy" than some of the other methods (like TPM/MTM security rituals)
I'm seeing around.

hth

73 de Jeff