Request for help with port organisation: how to install several versions of data files

[Ryan Schmidt]

On Jul 2, 2013, at 05:42, Mojca Miklavec wrote:
> 
> So what is the difference between the two scenarios then? (Your
> suggestion was to do (b).)
> a) geant4.9.5 depends on geant-something-1.1 and
> geant-somethingelse-3.0; geant4.9.6 depends on geant-something-1.2 and
> geant-somethingelse-3.0
> b) geant4.9.5 depends on geant4.9.5-data and geant4.9.6 depends on
> geant4.9.6-data

The difference is: what happens when you now want geant4.9.6 to depend on geant-something-1.3? First of all, you have to increase the revision of geant4.9.6, thereby causing a rebuild. And after the upgrade, the user will have both geant-something-1.2 and geant-something-1.3 on their system, even if the user had upgraded with "sudo port -u upgrade"; the -u flag will uninstall the previous version of a port being upgraded, but MacPorts has no way of knowing that the geant-something-1.2 and geant-something-1.3 ports are in any way related so MacPorts will not uninstall geant-something-1.2 automatically. If upgrading the version of any data files happens often, the user will end up with many of these older ports still installed and active, and will have to go through many unnecessary geant4.x.y rebuilds on the way.


> When the user will switch from 4.9.5 to 4.9.6, the "something-1.1"
> will be left in either case. Except that in (b) also another copy of
> "somethingelse-3.0" will stay on the hard drive, so one will get a
> leftover of 600 MB instead of a leftover of 100 MB.

I'm not familiar with the frequency of geant4 releases. Which do you think will occur more frequently: that a user upgrades from the geant4.9.5 port to the geant4.9.6 port, or that you increase the version of one of the data files?


> The approach (b) would only work (= clean old files) if geant4 would
> depend on geant4-data and there would be no option to install two
> versions of geant4 or two versions of geant4-data.

I do not advocate that.


> Do you want to say that changing
>    name                geant4-data
>    version             1.0
> to
>    name                geant4-data
>    version             1.1
> or "revision 1/2/3/..."
> 
> will update all files?

Yes, my suggestion was that you have a geant4.9.5-data port and a geant4.9.6-data port, and whenever the version of any of the data files therein needs to be changed, you increase e.g. the geant4.9.5-data port's version or revision. That way the user rebuilds the geant4.9.5-data port, but geant4.9.5 itself does not need to be rebuilt, or even touched at all.


>> But be clear that the file you download from upstream could already be compromised, if it's only being verified by an md5 checksum. Thus, you could be generating new "secure" checksums of an already compromised file.
> 
> Sure. But where should I get the checksums from? If the files are
> already compromised when the maintainer downloads them, so can be the
> published checksums. What then? (Or, one of the Geant4 developers can
> just as well put some evil or at least vulnerable code into the
> official distribution. Who is going to notice?)
> 
> I'm not saying that there is no security risk, but if it gets
> compromised to that level, there's not much one can do.


Certainly if a malicious hacker can replace the software tarball on the original site with an altered version, they can probably replace the checksums on the web page as well.

But I want to make sure you understand that because of flaws in the md5 algorithm that make it possible to create collisions, the following events can occur:

* developer releases new version of software, publishing its md5 checksum
* later, a hacker releases a different tarball containing malicious software but which has the same md5 checksum; perhaps they cannot post it to the original server, but maybe they can compromise a mirror.
* you write a portfile for the new version, fetching the file from a compromised mirror; you verify the md5 checksum with what upstream published and it matches; you generate new rmd160 and sha256 checksums of the compromised file and put them in the portfile
* the software you now install via the portfile is not the software the developer developed

The solution is for upstream to cease using md5 as their distfile integrity verification method and switch to an algorithm that does not have such vulnerabilities.