Filename in sha256sum doesn't match actual downloaded filename

[Pieter Frenssen]

In #181 the sha256sums of the latest downloads were fixed but there is still one small problem with the generated checksums:

For the "dynamic" downloads the filename in the sha256sum doesn't match the actual filename that is being downloaded. For example, when the "Latest stable" is downloaded, the filename is composer-stable.phar, but the sha256sum shows composer.phar:

82ea8c1537cfaceb7e56f6004c7ccdf99ddafce7237c07374d920e635730a631  composer.phar

This causes problems with tools that download filenames alongside their checksums in one step, such as Ansible.

These are the affected files:

• Latest Stable
• Latest Preview (alpha/beta/RC)
• Latest Snapshot
• Latest 1.x
• Latest 2.x

Possibly a good solution could be to make the dynamic downloads also available in their own dedicated folders, like is done for the versioned downloads. For example the latest stable release could be offered at https://getcomposer.org/download/latest-stable/composer.phar.

The current URLs (e.g. https://getcomposer.org/composer-stable.phar) should be kept so that existing users can keep using them, but this can be solved with symlinks.

[Stephan Eicher]

For our (currently internal only) puppet module we use the .sha256 uri instead of the .sha256sum uri because of the filename mismatch.

composer::instances:
  composer-1:
    checksum_url: https://getcomposer.org/composer-1.phar.sha256
    source: https://getcomposer.org/composer-1.phar
  composer-2:
    checksum_url: https://getcomposer.org/composer-2.phar.sha256
    source: https://getcomposer.org/composer-2.phar

They seem to be working at least for (we are not using anything else):

• Latest 1.x (will be dropped soon by us)
• Latest 2.x

[synace]

@Seldaek download_1x_bc route not working as expected?

curl -I https://getcomposer.org/composer-1.phar
HTTP/2 500

[Jordi Boggiano]

Yup I'm aware, will fix shortly.