On Tue, 10 Oct 2006 10:55:48 -0400 Dale Blount 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

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 (Роман Кирилич)

2006/10/11, Aaron Griffin :

...

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 (Роман Кирилич)

2006/10/11, VMiklos :

...

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 (Роман Кирилич)

2006/10/11, Alessio mOLOk' Bolognino :

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 (Роман Кирилич)

On Wed, 11 Oct 2006 10:57:53 -0500 "Aaron Griffin" 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

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 (Роман Кирилич)

2006/10/12, Cameron Daniel :

On Thu, 12 Oct 2006 00:06:44 +0300 "Roman Kyrylych" 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 Wed, 11 Oct 2006 23:57:45 +0300 "Roman Kyrylych" wrote:

Hi!

2006/10/11, Jason Chu :

...

On Wed, 11 Oct 2006 10:57:53 -0500 "Aaron Griffin" 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

On 10/10/06, Dale Blount 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 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....

On 10/10/06, Christian Hamar 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.

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 :

On Tue, Oct 10, 2006 at 09:48:21AM -0500, Aaron Griffin 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 (Роман Кирилич)

2006/10/11, Essien Ita Essien :

...

...

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 (Роман Кирилич)