There is some flexibility in how a project's dist directory is organized. It seems pretty common for projects to create a directory for each version. We could begin doing this and put the script files in each version directory: dist/vcl/2.4.2/vcl-install.sh dist/vcl/2.4.2/vcl-install.sh.sha1 dist/vcl/2.4.2/vcl-install.sh.asc
We could then create a symlink named something like "current" which points to the most recent release: dist/vcl/current -> dist/vcl/2.4.2/ Correct me if I'm wrong because I'm no signing expert, but wouldn't things work correctly if someone were to download: dist/vcl/current/vcl-install.sh dist/vcl/current/vcl-install.sh.sha1 dist/vcl/current/vcl-install.sh.asc There is a precedent for using symlinks. See: https://archive.apache.org/dist/flume/ https://archive.apache.org/dist/pig/ (using "stable" and "latest") https://archive.apache.org/dist/zookeeper/ (using "current" and "stable") If something like this is agreed upon, would there be anything preventing us from moving existing releases into directories? -Andy On Thu, Mar 26, 2015 at 10:34 AM, Josh Thompson <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When creating the vcl-install.sh and vcl-upgrade.sh scripts, I planned to > be > able to distribute them separately from the release artifacts (in addition > to > being within the artifacts) so that someone only needs to download the > script, > and the script will handle downloading and validating the artifact. It > makes > sense to distribute them from the same dist location as the release > artifacts > since that is the official release location. The scripts contain the > version > number to install. Because they have a version number, they need to be > updated in the dist location for each release. However, for the same > reason > that we couldn't update the 2.4 release after the bug was found in it > before > we announced it, we can't just update the files with each release without > triggering a possible security issue. > > As a solution, I thought maybe we could have scripts in the dist location > that > have a version number as part of the file name and use symlinks to point to > the latest version, updating the symlinks at each release. However, this > doesn't work for the signature files, since the signature files have the > original filename in them (that includes the version number). So, when an > attempt to verify the signature is done, the file listed in the signature > is > not found. As an example: > > download vcl-install.sh (which is a symlink to vcl-install-2.4.1.sh) > download vcl-install.sh.sha1 (which is a symlink to > vcl-install-2.4.1.sh.sha1) > verify .sha1 file: sha1sum -c vcl-install.sh.sha1 > sha1sum: vcl-upgrade-2.4.1.sh: No such file or directory > > Interestingly, verifying the .asc GnuPG signature still works. > > Before attempting yet another solution that may not work, I thought I'd > bring > it up on the list to seek input. What I'm thinking to do now is to add a > 'scripts' directory under the dist folder. Then, add version number > folders > under there, with the install and upgrade scripts in each version number > folder, like: > > dist/vcl/scripts/2.4.1/vcl-install.sh > dist/vcl/scripts/2.4.1/vcl-install.sh.sha1 > dist/vcl/scripts/2.4.1/vcl-install.sh.asc > dist/vcl/scripts/2.4.1/vcl-upgrade.sh > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.sha1 > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.asc > > When the next version comes out, we would just add a new release number > under > the scripts folder. > > Does this sound like a good idea? Other suggestions? > > Thanks, > Josh > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlUUGOwACgkQV/LQcNdtPQPvTwCbBfQkNbODUBJ+q+ix6oqqvRs2 > S4gAn33QxEo37/+3SS1+YGqM+hca6w7K > =2aUo > -----END PGP SIGNATURE----- > >
