Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Never repackage a release with same version number #5126

Closed
hansfn opened this issue May 9, 2014 · 6 comments
Closed

Never repackage a release with same version number #5126

hansfn opened this issue May 9, 2014 · 6 comments
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.

Comments

@hansfn
Copy link

hansfn commented May 9, 2014

Hi, I'm the maintainer of the Piwik port (package) in FreeBSD - see http://www.freshports.org/www/piwik/

FreeBSD ports require the files from a release to be unchanged - same size and MD5 sum. If not, the port will not install or update.

It seems the Piwik team has a practice of repackaging without changing version number for minor changes. This has happened many times - recently with the 2.2.1 release (where vendor/sebastian was removed).

I urge you to stop with this practice. AFAICT it's not good for security and very bad for FreeBSD ports and other package management solutions that build from source.

@mattab
Copy link
Member

mattab commented May 9, 2014

Thanks for the feedback!

As release manager I really try to avoid doing this as I know it's bad and causes troubles. But IMO it's still better than doing another point release just to fix a non critical bug in the release itself (such as the missing manifest file).

So I will do my best to not have to re-package like we did recently, but I cannot promise that I will follow the best practise.

Thanks a lot for your work packaging Piwik for FreeBSD!

@anonymous-matomo-user
Copy link

Hello, my name is John Marino.
I am one of the many people authorized to commit to FreeBSD ports.

I strongly urge the piwik project to follow the best practice under every circumstances. The act of creating a new tarball with the same name is called "rerolling". No package system can tolerate rerolling: not Debian, not Fedora, not pkgsrc, and not FreeBSD Ports collection.

If the hash digest doesn't match, the port is rejected as a man-in-the-middle attack. How can a user be sure the distribution file doesn't contain malware after the checksum fails?

From my point of view, if piwik continues this frankly amateur approach to releases, there are only two possible outcomes:

  1. Some release will have to be stored on FreeBSD servers, Freezing it in time. No update from that point will show for users

  2. piwik will simply be removed for being a bad citizen.

I would like to iterate that this is not a BSD thing - Linux package system abhor this practice too. It's a really, really bad thing. I urge you to release as many point releases as necessary and never, ever produce a new tarball with a previously used filename.

Sincerely and regards,
John

@anonymous-matomo-user
Copy link

btw, I think "point release" is the wrong term. It's not a new release, it's just a revision on the packaging. I suggestion something like

piwik-2.2.2.tar.gz => piwik-2.2.2a.tar.gz => piwik-2.2.2b.tar.gz

so the naming makes it clear it's the name release, but the contents of the tarball have changed. Pick whatever scheme you want; the only requirement is that each name is unique.

@mattab
Copy link
Member

mattab commented May 13, 2014

Hi John, thanks for your points... To prevent most errors of repackaging, please consider waiting 48 hours before issuing the FreeBSD port. This should prevent the problem in most cases... Cheers

@mattab
Copy link
Member

mattab commented May 14, 2014

In 23c6586: Display the SHA1 checksum in the email to Microsoft Web App team, after building a stable release.

Refs #5126 I apologise in advance for again re-packaging 2.2.2..

We agree with you that is not acceptable policy from us.
So we are now committed to you guys the FreeBSD community, and to Microsoft, to never re-package a release from now on.

Cheers

@mattab
Copy link
Member

mattab commented May 26, 2014

In 04700b9: Fixes #5126 Adding code that will fail the release script, if attempt to re-package an existing version.

sabl0r pushed a commit to sabl0r/piwik that referenced this issue Sep 23, 2014
…er building a stable release.

Refs matomo-org#5126 I apologise in advance for again re-packaging 2.2.2..

We agree with you that is not acceptable policy from us.
So we are now committed to you guys the FreeBSD community, and to Microsoft, to never re-package a release from now on.

Cheers
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

3 participants