Package Details: rar 5.4.0-1

Git Clone URL: https://aur.archlinux.org/rar.git (read-only)
Package Base: rar
Description: A command-line port of the rar compression utility
Upstream URL: http://www.rarlab.com
Keywords: rar unrar
Licenses: custom
Conflicts: rar-beta
Submitter: None
Maintainer: taylorchu (FadeMind)
Last Packager: FadeMind
Votes: 681
Popularity: 3.587629
First Submitted: 2008-10-15 21:38
Last Updated: 2017-01-18 19:57

Latest Comments

WorMzy commented on 2017-05-30 08:25

All a matching checksum means is that you have probably* downloaded the same file as the maintainer. The point I'm trying to make is that the checksum in the PKGBUILD isn't necessarilly more valid/secure than the ones other people are reporting in the comments. You argue that only the checksum reported by the maintainer is secure, I argue that no checksum is -- checksums should not be used to verify the validity of a file, only it's integrity.

See also: https://wiki.archlinux.org/index.php/PKGBUILD#Integrity

* apparently it's possible to have two completely different files have a matching md5sum, so this isn't guaranteed.

eang commented on 2017-05-29 16:16

@WorMzy

> What makes you so sure that the maintainer won't simply run updpkgsums and resubmit the package?

I can download the tarball and manually check its checksum with the one claimed in the PKGBUILD.

> How will you know if they do this or liase with upstream

We can't know for sure. But this doesn't mean we should ignore the checksum verification altogether.

> How do you know if /any/ package maintainer verifies the source checksums with upstream?

Some do. Again, just because some maintainers don't care doesn't mean we should expose ourselves by ignoring the checksum verification.

theforeigner commented on 2017-05-26 08:50

The md5sum for rar.1 (whatever that is?) has also changed: 4cffd2771bb4a51e4a68500d799550d8

bric3 commented on 2017-05-24 12:15

For future readers, I edited the PKGBUILD file when asked

The MD5 checksums of source files (respectively http://www.rarlab.com/rar/rarlinux-5.4.0.tar.gz and http://www.rarlab.com/rar/rarlinux-x64-5.4.0.tar.gz)
md5sums_i686=('efa2a5a29f57f34999a9bae355510618')
md5sums_x86_64=('d02b8742478d5e6428c12ee14b2a678d')

And as rarlab removed rar_static, I commented this line :

# install -Dm755 rar_static "${pkgdir}/usr/bin/rar_static"

Jristz commented on 2017-05-14 03:07

I agree that the maintainer need update the pkg, but now that is dynamicaly linked the maintainer probably now need to listed all the deps that rar link.

Musikolo commented on 2017-05-13 16:12

@All,

I got a reply from one of the developers of Rarlab about the checksum change. This is a short snippet of his reply:

"We received a complain from Debian maintainers that statically linked rar violates LGPL:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860952;msg=5

and updated:
- http://rarlab.com/rar/rarlinux-5.4.0.tar.gz
- http://rarlab.com/rar/rarlinux-x64-5.4.0.tar.gz

to remove rar_static from the package. These files on rarlab.com are valid and our server is not compromised."

@FadeMind, since everything seems to be alright, would you mind updating the package accordingly?

Thank you!

Musikolo commented on 2017-05-13 03:33

I just sent an email to the Rarlab development team - http://www.rarlab.com/feedback.htm

I hope to get a reply shortly that helps close this discussion.

Regards.

WorMzy commented on 2017-05-12 17:16

Interesting theory. What makes you so sure that the maintainer won't simply run updpkgsums and resubmit the package? How will you know if they do this or liase with upstream? How do you know if /any/ package maintainer verifies the source checksums with upstream?

eang commented on 2017-05-12 17:05

This package should be considered unsafe until his maintainer doesn't update the checksum in the PKGBUILD (after checking that the tarball is ok). If you manually change the checksum in your local PKGBUILD you are just exposing yourself to a potential attack.

Musikolo commented on 2017-05-09 00:20

@spirtbrat/Pietro_Pizzi thanks for your replies. Everyone is right!

My concern comes from the fact that the checksum shouldn't change once the maintainer updates the PKGBUILD for any given version. Any change without further notice is a reason to suspect the file is no longer secure, and/or the server where the file is stored could have been potentially compromised.

If anyone was able to build version 5.4.0 64-bit with the checksum available in the PKGBUILD (f7181c0aed3b7be402b95185bd61e646), then Houston, we have a situation! The file could have been compromised in the server. It's also possible the RarLab team has legitimately modified the file, but IMO that's very unlikely.

However, if nobody was able to build it and everyone was ever getting the same issue, then the maintainer might have forgotten or used the wrong checksum. New checksum is d02b8742478d5e6428c12ee14b2a678d.

So, just to clarify, has anyone being able to build the package with the old checksum (f7181c0aed3b7be402b95185bd61e646)?

Thank you!

All comments