[pacman-dev] $ARCH suffix on packages
So I actually expected someone to start this, as I was curious. I know frugalware uses the architecture suffix on packages, and Xentac thinks this is a good idea. I'd like to hear reasons. I don't really feel that "RPM and DEB do it" is a good enough reason. I mean, if that reason was good enough, we'd be using RPM/DEB in place of pacman packages. The way I see it, I don't think pacman needs to know the architecture it's running on. Installing "pkg-foo" should be no different on i686 or PPC. Therefore, I think that adding the architecture suffix is extra information that's not really needed. What is gained by having this suffix?
What is gained by having this suffix?
Say I have more than one architecture running Arch (I do). Say I have an nfs mounted home directory (I do). Say I have packages lying around in my homedir (I do). It'd be nice to know at a glance which box(es) the package could be installed on without stretching my already over-stuffed memory. Same holds true for packagers who build packages for more than one architecture. Dale
Hey.
I'd like to hear reasons. I don't really feel that "RPM and DEB do it" is a good enough reason. I mean, if that reason was good enough, we'd be using RPM/DEB in place of pacman packages.
:)
The way I see it, I don't think pacman needs to know the architecture it's running on. Installing "pkg-foo" should be no different on i686 or PPC. Therefore, I think that adding the architecture suffix is extra information that's not really needed.
What is gained by having this suffix?
brr. Sorry, i really dont know why we started to using $ARCH suffix in frugalware, vmiklos will answer this. But. In my opinion if a user pulls a package from anywhere, from web or from ftp or just he is store packages in cd or dvd, etc, then he/she can see that what is this pack. I mean for which architecture. Just seeing the filename and you know that foo-1.0-1-x86_64 is for x86_64 archs, -i686 for i686 archs. So users not confused to see foo-1.0-1 and foo-1.0-1 and user just thinks, "what the hell, two same package? install that one then" And maybe he install an i686 package to x86_64 arch :) I know you will answer something like this: we store our packages in distro-i686/ distro-x86_64/ dirs and why need an extra SUFFIX. Because of that. If you find a package somewhere or you got a mirror or a backup sometimes you want to know from the filename that package is for what architecture. Think a good idea this, and this seems some "standard" nowadays. I know you said not to say that RPM/DEB do this :) but then i says most major distribution do this scheme whatever its pkgmanager. (except slackware) Regards -krix-
On 10/10/06, Dale Blount <dale@archlinux.org> wrote:
Say I have more than one architecture running Arch (I do). Say I have an nfs mounted home directory (I do). Say I have packages lying around in my homedir (I do). It'd be nice to know at a glance which box(es) the package could be installed on without stretching my already over-stuffed memory.
On 10/10/06, Christian Hamar <krics@gds.hu> wrote:
In my opinion if a user pulls a package from anywhere, from web or from ftp or just he is store packages in cd or dvd, etc, then he/she can see that what is this pack. I mean for which architecture. Just seeing the filename and you know that foo-1.0-1-x86_64 is for x86_64 archs, -i686 for i686 archs. So users not confused to see foo-1.0-1 and foo-1.0-1 and user just thinks, "what the hell, two same package? install that one then" And maybe he install an i686 package to x86_64 arch :)
So ok, I was going the wrong route when thinking about this. Nothing is really gained from pacman's perspective, and pacman doesn't require it in any way, it just alleviates confusion for users and packagers and any other thing that consumes the packages that is NOT written in a programming language (like me, though some may argue I AM, in fact,written in a programming language, called DNA, but I digress....) Coming at it from this angle, I think this may actually be a good idea across the board. Xentac, do you remember where the argument ended up when this was brought up before? Being that pacman3 will probably be side-by-side installed with pacman2 for a bit, while we iron things out, is there a way to smooth the transition? Perhaps a temporary "check for the arch version, if not found, try without the arch name" until we can move everything over... assuming, of course, that we do move to this scheme. PS I'm thinking of doing a side-by-side pacman3 RC in [unstable] sometime between wed and fri, for any archers interested....
Dale Blount wrote:
What is gained by having this suffix?
Say I have more than one architecture running Arch (I do). Say I have an nfs mounted home directory (I do). Say I have packages lying around in my homedir (I do). It'd be nice to know at a glance which box(es) the package could be installed on without stretching my already over-stuffed memory.
Same holds true for packagers who build packages for more than one architecture.
yeah... its actually good for ppls that have to download and keep packages lying around, and then manually add them with pacman -A, instead of pacman -S. I think Arch as a community actually encourages pacman -S *unconciously* over pacman -A, so this hasn't been much of a problem in our faces, but its a good thing to have, because once in a while, you want to know.
Dale
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Being that pacman3 will probably be side-by-side installed with pacman2 for a bit, while we iron things out, is there a way to smooth the transition? Perhaps a temporary "check for the arch version, if not found, try without the arch name" until we can move everything over... assuming, of course, that we do move to this scheme.
For backward compatibility. The way what you write down now is fully walkable :) I mean we did many "non-compatible" patch to pacman. Like, libarchive, md5->sha1, gzip->bzip2. But we solved compatibility issues via that way what you wrote here. A simple example. At that time we migrated to sha1 then we not rebuild all of our packages with new pacman. We just hold MD5 field for backward compatibility and put a new SHA1 field. Packages are created newly got only SHA1 field in pkginfo and in other places. Packages that still not rebuilt got MD5 field and not sha1sum. So what i mean. We made a patch that pacman detect if a package got SHA1 field, then operates with SHA1 funcs. IF MD5 detected (old package, not recompiled) then using MD5 funcs. Same with gzip->bzip2 migration and with libarchive. So in here as you wrote, i dont think that hard to implement in pacman that handle -$ARCHS and original packages in same time. Maybe gensync need some trick. But i think its easy to code this into pacman and be backward compatible. Since all of our patches was backward compatible. (only this -$ARCHS one not made for backward compatible, because when we made that archlinux does not got any other arch (now it got) ) Second line (not so specific to frugalware :) specific to archlinux ! ): The pacman2 and pacman3 at same time think a bad idea. As i mentioned sha1, bzip2, libarchive patchs are all backward compatible and worked when we upgraded from pacman2 -> pacman3 in frugalware. We not rebuilt the whole of our packages. There was no such need. By time, new features integrated automatically into new packages or rebuilded pacakges, because makepkg was forced to implement new stuffs (eg.: bzip2 packs, sha1sum, sha1sum in fdb, etc) . I dont see any point to use pacman2 && pacman3 in same time. But i dont got rights to made it, because i'm not an archlinux developer :) Of course this is archlinux releated and archlinux devels need to see whats the point. This was just an idea and a comment about our patches. Regards Christian Hamar alias krix Hungary
On 10/10/06, Christian Hamar <krics@gds.hu> wrote:
I dont see any point to use pacman2 && pacman3 in same time. But i dont got rights to made it, because i'm not an archlinux developer :) Of course this is archlinux releated and archlinux devels need to see whats the point.
It's only for testing / evaluation purposes. I don't want to have people just install pacman3 if there are bugs in it. I want them to be able to install pacman3, mess with it, find a bug, then use pacman2 to continue what they're doing. The side-by-side installation will only be for a small period of time while we do some testing.
On Tue, 10 Oct 2006 10:18:29 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Coming at it from this angle, I think this may actually be a good idea across the board. Xentac, do you remember where the argument ended up when this was brought up before?
I had said that we could get around the filename parsing problem (ambiguities in pkgver, pkgrel parsing) by extracting the metadata from the tarball and including the package's filename in the db. Then it got shouted down by people saying that we shouldn't break backwards compatibility and all packages should be stored in the repo layout anyway, so there are no good reasons to change it. I also brought up the finding a random package argument, but no one wanted to hear it. *All* packages had to be installed from the repos that were broken up into those architectures... Jason
On Tue, Oct 10, 2006 at 09:48:21AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What is gained by having this suffix?
all my reasons are already mentioned here, so i just would like to sum up them: 1) protecting users from installing x86_64 packages on i686, or so 2) being able to use a common cache for different architectures 3) regarding the "it's not necessary, pacman can extract that info from .PKGINFO": the situation is the same with pkgver/pkgrel, too. why do we have them in the package name? i think because of 1) and 2) (oh and a 4) is about prodecting developers to mess up the packages, but the no1 is the user so this should not be a reason) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
As an ordinary user I must say that $ARCH suffix in package names is _not_ needed IMHO. Why? Some of you say it will be usefull for people who download packages for more then one arch and add them with pacman -A. But is that _hard_ to keep them in different directories? Why then we don't end with something like modules-something-beyond-utils-0.15-7-i686-2.6.18-testing.pkg.tar.gz for better seeing "at a glance" all info??? If going with that logic - at least having -testing/{-curent/extra/}unstable is good for such people who needs -i688/-x86_64, why don't add this too? >;-) Seriously, _most_ people don't use multiple archs at once nor install much packages with pacman -A nor keep a mirror of different archs in one huge directory. Having some prefix is useful for them. They _already_know_ for what arch are packages they are installing. IMHO adding $ARCH suffix will only complicate things. And will confuse many users during transition period (which will last untill all packages will got $ARCH suffix appended during version updates). So, I don't see anything positive for _most_ users here. -- Roman Kyrylych (Роман Кирилич)
2006/10/11, VMiklos <vmiklos@frugalware.org>:
On Tue, Oct 10, 2006 at 09:48:21AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What is gained by having this suffix?
all my reasons are already mentioned here, so i just would like to sum up them:
1) protecting users from installing x86_64 packages on i686, or so
Heh? $ARCH suffix is just a part of filename. Only arch=(...) in .PKGINFO really should matter (and "protect"). Or I'm missing something?
2) being able to use a common cache for different architectures
Well, if you talk about /var/cache/pacman/pkg/ - then yes. But for what it's needed? Anyway if user uses x86_64 then all packages installed on his system are for x86_64, and those that are i686 only (binary games or flash plugin for example) simply don't have their x86_64 couterparts.
3) regarding the "it's not necessary, pacman can extract that info from .PKGINFO": the situation is the same with pkgver/pkgrel, too. why do we have them in the package name? i think because of 1) and 2)
No, it's not because 1) and 2). It's because it's needed for keeping multiple versions of package in /var/cache/pacman/pkg/. (i suppose pacman won't use cvs for that ;-) )
(oh and a 4) is about prodecting developers to mess up the packages, but the no1 is the user so this should not be a reason)
-- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2006/10/11, VMiklos <vmiklos@frugalware.org>:
On Tue, Oct 10, 2006 at 09:48:21AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
What is gained by having this suffix?
all my reasons are already mentioned here, so i just would like to sum up them:
1) protecting users from installing x86_64 packages on i686, or so
Heh? $ARCH suffix is just a part of filename. Only arch=(...) in .PKGINFO really should matter (and "protect"). Or I'm missing something?
yes, you're missing something :) Why we're not complaining right now is that there is really no large community using pacman. If there was a Non-ArchLinux/Frugalware site that keeps thirdparty pacman pkgs (something akin to rpmfind.net, etc), you'll immedietly see why its neccessary for the person downloading. Also, if like me, you keep having to build packages for different architectures, and keep them around on your system, yes, you can put them in different directories, but its slightly a more resilient design if the packages carry the info with them programmatically (via arch=(foobar) in PKGBUILD) and visually foobar-x.y-z.ppc.pkg.tar.gz. Its not exactly a show stopper, but its a *good* decision (i see more advantages than disadvantages). <snip>
2006/10/11, Essien Ita Essien <essiene@datavibe.net>:
1) protecting users from installing x86_64 packages on i686, or so
Heh? $ARCH suffix is just a part of filename. Only arch=(...) in .PKGINFO really should matter (and "protect"). Or I'm missing something?
yes, you're missing something :)
Why we're not complaining right now is that there is really no large community using pacman. If there was a Non-ArchLinux/Frugalware site that keeps thirdparty pacman pkgs (something akin to rpmfind.net, etc), you'll immedietly see why its neccessary for the person downloading.
Wrong example , IMHO. :-) rpmfind.net and other such sites are evil, IMHO. :-) How user can be sure that rpm he downloads will work on his distro? It can be compiled with different gcc, glibc, dependencies, use different file structure etc. It's just file format. Users should download packages from their distro's (or unofficial users') repos _only_, IMHO.
Also, if like me, you keep having to build packages for different architectures, and keep them around on your system, yes, you can put them in different directories, but its slightly a more resilient design if the packages carry the info with them programmatically (via arch=(foobar) in PKGBUILD) and visually foobar-x.y-z.ppc.pkg.tar.gz.
Its not exactly a show stopper, but its a *good* decision (i see more advantages than disadvantages). <snip>
That's more a matter of taste, I suppose. I don't try to say that IMHO starting using $ARCH will be a terrible mistake. But I don't see enough advantages for making this change. -- Roman Kyrylych (Роман Кирилич)
On Tue, 10 Oct 2006 10:55:48 -0400 Dale Blount <dale@archlinux.org> wrote:
Say I have more than one architecture running Arch (I do). Say I have an nfs mounted home directory (I do). Say I have packages lying around in my homedir (I do). It'd be nice to know at a glance which box(es) the package could be installed on without stretching my already over-stuffed memory.
Same holds true for packagers who build packages for more than one architecture.
Dale
I think the $ARCH suffix is a good idea. Yeah it's a change which will confuse people who don't stop and think for half a second and while it doesn't have any technical benefits, the cosmetic convenience would be nice. Have the $ARCH suffix in the filename isn't going to add any unnecessary bloat, it's not going to take away from anything and while the positive side isn't anything that will blow you away, it has more minimal advantages than minimal disadvantages. - Cameron
On 10/11/06, Cameron Daniel <me@camdaniel.com> wrote:
Have the $ARCH suffix in the filename isn't going to add any unnecessary bloat, it's not going to take away from anything and while the positive side isn't anything that will blow you away, it has more minimal advantages than minimal disadvantages.
It's also worth point out that if Arch subconciously wants users to -S instead of -A, there' no difference at all. I mean "pacman -S foo" doesn't care what version, release, or architecture foo is, it just installs it.
OK, it seems most devs agree to have $ARCH in package filename. Hmm.. but what about pacman2. Will there be a new version that will handle this? And, when we are going to change filenames of all packages, then why not to change tar.gz to tar.bz2 and md5sum to sha1sum (or even sha512sum) at the same time? -- Roman Kyrylych (Роман Кирилич)
On 10/11/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
OK, it seems most devs agree to have $ARCH in package filename. Hmm.. but what about pacman2. Will there be a new version that will handle this?
This will be thought of. No one wants to break anything. We will not get ahead of ourselves. I think most of the collaborators here have enough programming experience to know how to handle things like this.
And, when we are going to change filenames of all packages, then why not to change tar.gz to tar.bz2 and md5sum to sha1sum (or even sha512sum) at the same time?
a) bz2 is slower to decompress. Adding CPU time for a slight amount of bandwidth saving etc etc, I can go on and on... libarchive should handle this regardless... it may actually work right now... personally, I don't really care. I just want my crap installed as fast as possible b) I don't feel that anything is gained from using sha1sums. md5 is the defacto file integrity check. We're not using md5 as a cryptographic algorithm, we're checking file integrity Regardless, you're getting ahead here... neither of these issues has been discussed at all. We need to take this one step at a time. Applying 30 changes then saying "poof, use this" is never a good idea.
2006/10/11, Aaron Griffin <aaronmgriffin@gmail.com>:
And, when we are going to change filenames of all packages, then why not to change tar.gz to tar.bz2 and md5sum to sha1sum (or even sha512sum) at the same time?
a) bz2 is slower to decompress. Adding CPU time for a slight amount of bandwidth saving etc etc, I can go on and on... libarchive should handle this regardless... it may actually work right now... personally, I don't really care. I just want my crap installed as fast as possible
I know that bz2 decompressing is slower, but does "as fast as possible" also include downloading time? bz2 will be downloaded faster, because it has less size. ;-)
b) I don't feel that anything is gained from using sha1sums. md5 is the defacto file integrity check. We're not using md5 as a cryptographic algorithm, we're checking file integrity
Then why Frugalware guys use it instead of md5 now? What advantages it gives them? I'm just curious.
Regardless, you're getting ahead here... neither of these issues has been discussed at all. We need to take this one step at a time. Applying 30 changes then saying "poof, use this" is never a good idea.
I understand, but "one step a time" can be not so good if there will be few something-breaking steps instead of one. OK, I don't want to go too much ahead. So I'll wait until right time comes... :-) -- Roman Kyrylych (Роман Кирилич)
On Wed, 11 Oct 2006 10:57:53 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
b) I don't feel that anything is gained from using sha1sums. md5 is the defacto file integrity check. We're not using md5 as a cryptographic algorithm, we're checking file integrity
I talked to Judd about this one. I'd noticed it while at LinuxTag a couple years back... While, on the surface we use md5sums to check file integrity, during building we use it to verify that two downloads (at different time periods) are the same. In this situation, it's possible to craft a malicious tarball that matches the md5sum but has a different payload. JGC was the one who suggested we use md5sums and sha1sums together because it's much more difficult to craft something malicious that matches both of them. I wrote a patch for makepkg a long time ago, but Judd didn't accept it because sha1sums were a lot longer and looked ugly in a PKGBUILD. Jason
On Wed, Oct 11, 2006 at 07:21:40PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Then why Frugalware guys use it instead of md5 now? What advantages it gives them? I'm just curious.
with md5sum, it's almost trivial to make collosions. mirrors can change packages without having the md5sum changed. with sha1, this is much more difficult and of course we know that sha1 is not a cryptographical algorithm, either. i plan to came up with an "optional support for gpg signatures" patch, just it's far from complete at the moment
Regardless, you're getting ahead here... neither of these issues has been discussed at all. We need to take this one step at a time. Applying 30 changes then saying "poof, use this" is never a good idea.
agree. that's one of the main reasons we don't want to fork pacman. when Judd/Aaron/Aurelien merges our patches they are reviewed carefully and you know, the more people review the code, the more bug we find. also they have genious ideas sometimes :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
2006/10/11, VMiklos <vmiklos@frugalware.org>:
Then why Frugalware guys use it instead of md5 now? What advantages it gives them? I'm just curious.
with md5sum, it's almost trivial to make collosions. mirrors can change packages without having the md5sum changed. with sha1, this is much more difficult
and of course we know that sha1 is not a cryptographical algorithm, either. i plan to came up with an "optional support for gpg signatures" patch, just it's far from complete at the moment
That's what I was thinking about. I know that there was more than enought articles about collisions in MD5 algorithm recently. And I don't think that using more secure hashing algorithm is paranoic. IMHO SHA-512 (which is _not_the_same_ as SHA1) will be right choice. GPG is much more complex to implement. But I see another thread about this is started, so let move there. -- Roman Kyrylych (Роман Кирилич)
Hi! 2006/10/11, Jason Chu <jason@archlinux.org>:
On Wed, 11 Oct 2006 10:57:53 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
b) I don't feel that anything is gained from using sha1sums. md5 is the defacto file integrity check. We're not using md5 as a cryptographic algorithm, we're checking file integrity
I talked to Judd about this one. I'd noticed it while at LinuxTag a couple years back...
While, on the surface we use md5sums to check file integrity, during building we use it to verify that two downloads (at different time periods) are the same. In this situation, it's possible to craft a malicious tarball that matches the md5sum but has a different payload.
Yes, there were few security papers posted about MD5 collisions and how to use them.
JGC was the one who suggested we use md5sums and sha1sums together because it's much more difficult to craft something malicious that matches both of them. I wrote a patch for makepkg a long time ago, but Judd didn't accept it because sha1sums were a lot longer and looked ugly in a PKGBUILD.
Mmm... I don't think that using md5sum & sha1sum at the same time will make things more secure. md5sum will not matters in that case, because security will depend on the strongest part in such case, which is, obviously, sha1sum. I propose to use SHA-512 instead which is basically a stronger version of SHA1. I have much practical experience and theoretical knowledge to say that this will be the best choice in terms of both security and simplicity of implementation. -- Roman Kyrylych (Роман Кирилич)
On 23:48 Wed 11 Oct , Roman Kyrylych wrote:
2006/10/11, VMiklos <vmiklos@frugalware.org>:
Then why Frugalware guys use it instead of md5 now? What advantages it gives them? I'm just curious.
with md5sum, it's almost trivial to make collosions. mirrors can change packages without having the md5sum changed. with sha1, this is much more difficult
and of course we know that sha1 is not a cryptographical algorithm, either. i plan to came up with an "optional support for gpg signatures" patch, just it's far from complete at the moment
That's what I was thinking about. I know that there was more than enought articles about collisions in MD5 algorithm recently. And I don't think that using more secure hashing algorithm is paranoic. IMHO SHA-512 (which is _not_the_same_ as SHA1) will be right choice. GPG is much more complex to implement.
But I see another thread about this is started, so let move there.
-- Roman Kyrylych (Роман Кирилич)
Why don't use both md5 and sha1 ? I don't mean md5 OR sha1, but md5 AND sha1. _I_think_ it's virtually impossible to fuck two different hash algorithm. P.s. I'm just an arch user :) -- Alessio 'mOLOk' Bolognino
2006/10/11, Alessio mOLOk' Bolognino <themolok.ml@gmail.com>:
Why don't use both md5 and sha1 ? I don't mean md5 OR sha1, but md5 AND sha1. _I_think_ it's virtually impossible to fuck two different hash algorithm.
This won't make the system more secure. Read the sibling thread for this. Let move this discussion there. -- Roman Kyrylych (Роман Кирилич)
From the sibling thread:
Why don't use both md5 and sha1 ? I don't mean md5 OR sha1, but md5 AND sha1. _I_think_ it's virtually impossible to fuck two different hash algorithm.
This won't make the system more secure. Because if somebody has the resources to find a collision in SHA1 then I'm sure he/she/they can do the same with MD5. And if they cannot do this for SHA1 then MD5 doesn't matter. Only using SHA-512 or public key cryptography really solves security problems with both MD5 and SHA1. -- Roman Kyrylych (Роман Кирилич)
On 22:58 Wed 11 Oct , Alessio 'mOLOk' Bolognino wrote:
On 23:48 Wed 11 Oct , Roman Kyrylych wrote:
2006/10/11, VMiklos <vmiklos@frugalware.org>:
Then why Frugalware guys use it instead of md5 now? What advantages it gives them? I'm just curious.
with md5sum, it's almost trivial to make collosions. mirrors can change packages without having the md5sum changed. with sha1, this is much more difficult
and of course we know that sha1 is not a cryptographical algorithm, either. i plan to came up with an "optional support for gpg signatures" patch, just it's far from complete at the moment
That's what I was thinking about. I know that there was more than enought articles about collisions in MD5 algorithm recently. And I don't think that using more secure hashing algorithm is paranoic. IMHO SHA-512 (which is _not_the_same_ as SHA1) will be right choice. GPG is much more complex to implement.
But I see another thread about this is started, so let move there.
-- Roman Kyrylych (Роман Кирилич)
Why don't use both md5 and sha1 ? I don't mean md5 OR sha1, but md5 AND sha1. _I_think_ it's virtually impossible to fuck two different hash algorithm.
P.s. I'm just an arch user :)
Ok somebody else already said that, I didn't read the whole ml archive. -- Alessio 'mOLOk' Bolognino
On Wed, 11 Oct 2006 23:57:45 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
Hi!
2006/10/11, Jason Chu <jason@archlinux.org>:
On Wed, 11 Oct 2006 10:57:53 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
b) I don't feel that anything is gained from using sha1sums. md5 is the defacto file integrity check. We're not using md5 as a cryptographic algorithm, we're checking file integrity
I talked to Judd about this one. I'd noticed it while at LinuxTag a couple years back...
While, on the surface we use md5sums to check file integrity, during building we use it to verify that two downloads (at different time periods) are the same. In this situation, it's possible to craft a malicious tarball that matches the md5sum but has a different payload.
Yes, there were few security papers posted about MD5 collisions and how to use them.
Most of the ones I've seen talked about creating md5 collisions between two files, not creating a file with the same md5 as another file (there's a distinction).
JGC was the one who suggested we use md5sums and sha1sums together because it's much more difficult to craft something malicious that matches both of them. I wrote a patch for makepkg a long time ago, but Judd didn't accept it because sha1sums were a lot longer and looked ugly in a PKGBUILD.
Mmm... I don't think that using md5sum & sha1sum at the same time will make things more secure. md5sum will not matters in that case, because security will depend on the strongest part in such case, which is, obviously, sha1sum.
It's not about one over the other. It's the fact that you don't just have to find a sha1 collision or an md5 collision, but you have to find a sha1 collision *and* an md5 collision with a single file. If you find a sha1 collision without an md5 collision, changing the file to create an md5 collision will make them not match sha1 hashes anymore. It makes it much more computationally difficult.
I propose to use SHA-512 instead which is basically a stronger version of SHA1.
I don't have experience with many things other than md5 and sha1.
I have much practical experience and theoretical knowledge to say that this will be the best choice in terms of both security and simplicity of implementation.
I don't know how telling us you have experience helps you convince us... I do agree that having one hash over two is more simple. I don't necessarily agree that it's more secure. Jason
2006/10/12, Cameron Daniel <me@camdaniel.com>:
On Thu, 12 Oct 2006 00:06:44 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
This won't make the system more secure. Because if somebody has the resources to find a collision in SHA1 then I'm sure he/she/they can do the same with MD5. And if they cannot do this for SHA1 then MD5 doesn't matter.
Only using SHA-512 or public key cryptography really solves security problems with both MD5 and SHA1.
I think you're missing the point here. Using both doesn't just make it as strong as the strongest (sha1 here), sure someone could craft a tarball that matched the md5sum of the original tarball but then finding a sha1 collision and crafting the _same_ tarball to match both is going to be significantly more work if even possible.
Oh, it seems you are right. If didn't think about this issue, it's already 0:45 at my timezone and I'm a bit tired and my head is now working good :-). Nice explanation, BTW.
I'm for using bzip over gzip as well. It's trivial to implement with libarchive and while it adds CPU time, it decreases download size in some cases by a few hundred KB. Net connections still aren't as quick as I'm sure a lot of us would like ha, bzip would probably end up with the slightly quicker install.
Yes, especially for people with slow connections (some users still have dialup at <=33.6K!). -- Roman Kyrylych (Роман Кирилич)
On Thu, 12 Oct 2006 00:06:44 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
This won't make the system more secure. Because if somebody has the resources to find a collision in SHA1 then I'm sure he/she/they can do the same with MD5. And if they cannot do this for SHA1 then MD5 doesn't matter.
Only using SHA-512 or public key cryptography really solves security problems with both MD5 and SHA1.
I think you're missing the point here. Using both doesn't just make it as strong as the strongest (sha1 here), sure someone could craft a tarball that matched the md5sum of the original tarball but then finding a sha1 collision and crafting the _same_ tarball to match both is going to be significantly more work if even possible. I'm for using bzip over gzip as well. It's trivial to implement with libarchive and while it adds CPU time, it decreases download size in some cases by a few hundred KB. Net connections still aren't as quick as I'm sure a lot of us would like ha, bzip would probably end up with the slightly quicker install. - Cameron
Ooops... "now working good" => "NOT working good" :-D -- Roman Kyrylych (Роман Кирилич)
participants (9)
-
Aaron Griffin
-
Alessio mOLOk' Bolognino
-
Cameron Daniel
-
Christian Hamar
-
Dale Blount
-
Essien Ita Essien
-
Jason Chu
-
Roman Kyrylych
-
VMiklos