Talk:PKGBUILD

From ArchWiki
Revision as of 14:07, 19 July 2015 by Det (talk | contribs) (Integrity variables details: re + close)
Jump to: navigation, search

array writing style

When talking about arrays, should we separate them from variables with: array=(), e.g. makedepends, source_x86_64 vs. makedepends=(), source_x86_64=()? --Dettalk 06:52, 6 February 2015 (UTC)

Judging from [1] it should be the former, but does this mean if all arrays were converted to the name=() style, then it would be fine? —Dettalk 21:58, 6 February 2015 (UTC)
It would be fine consistency-wise, but I don't see the need to do it: it's not that there can be a non-array variable with the same name of an array one, so adding =() would only be redundant. I would consider instead using the first instances of variables in each section as anchors for links to other sections, e.g. #source, but I'd like to hear other opinions about this possibility. — Kynikos (talk) 04:49, 7 February 2015 (UTC)

Integrity variables details

I think this series of edits introduced too many details to PKGBUILD#Integrity variables, considering the scope of the page. I suggest removing the subintro (the table and the paragraph above) and reordering the sections like they were before (sha256sums on top). — Kynikos (talk) 03:44, 8 February 2015 (UTC)

That doesn't make much sense to me, considering how important those explanations between collision/preimage vulnerabilities are (there's a lot of confusion about this), and how little space they take. I would suggest moving the details elsewhere (of which there are pretty modestly, so a completely new page would look pretty dull) and including a "See also" note, but even then, there's no real reason to be advocating SHA-2 in terms of file integrity now or the near future.
Also, as explained by weirddan455, the more important part of integrity are the PGP signatures, not the checksums themselves. —Dettalk 03:56, 8 February 2015 (UTC)
The last time we discussed this issue, it was in [2]: that's when we made the switch to sha256sums in Arch packaging standards. Now, I agree that there's no advantage in security in using it over md5sums, but right because of that, what's the need of being so detailed about collisions? We don't really have a page where to move that information, maybe a link or two to Wikipedia would do better, but as a compromise I propose to merge that "subintro" into the various "*sums" subsections, and only keep a brief, 1-paragraph period there, that instead says explicitly, clearly and simply that choosing the hash algorithm doesn't influence the security of the download, and signatures should be used for that purpose.
Then, since it seems to me that what we're trying to achieve here is improving the performance (i.e. speed) of the hash calculation, especially for big files, since the difference wouldn't be noticeable for small files, we must also explicitly state that that's the reason to choose md5sums over the other algorithms, which is instead something that's currently completely absent in the section.
Kynikos (talk) 03:25, 9 February 2015 (UTC)
But why have we moved, when we're not even dealing with collisions? If that section was there back then, nobody probably would have suggested it.
I'm not even sure how to go on in life.. is SHA-256 now the "default", but you may arbitrarily pick MD5 as you see fit instead?
--Dettalk 20:12, 14 July 2015 (UTC)
I didn't suggest to remove the info on vulnerabilities, but to summarize it and clarify instead its (ir)relevance regarding integrity checking: this is what I meant in practice, please let me know what you think. — Kynikos (talk) 14:09, 16 July 2015 (UTC)
If this is cool, then everything is cool. I'm just thinking what happens now with the Packaging Standard?
Also, should there be a Template:Note about the "Checksums are intended to verify the integrity of the downloaded files, not their authenticity [...]"?
--Dettalk 15:06, 16 July 2015 (UTC)
Yes, your edit's perfectly fine for me, I'm glad you agree with my revisions too. Arch packaging standards is fixed with [3], thanks for the reminder.
In my view the "Checksums are intended..." paragraph fits very naturally there (i.e. I don't see it as "extraneous" according to Help:Style#Notes.2C_Warnings.2C_Tips), so I wouldn't use a Note there. If you're worried about its visibility, I'm pretty sure that the bolded "not" will attract even more attention than a Note template ;)
I'm closing this discussion, but please reopen it if you want to add something.
Kynikos (talk) 16:00, 17 July 2015 (UTC) (last edit: 08:06, 18 July 2015 (UTC))
Well, now actually, in this form, this sentence in #md5sums: "[...] but it is known to be vulnerable to collision attacks, and theoretically also to preimage attacks." ..starts sounding pretty irrelevant. Like you would care about flaws in a completely different, or a theoretical, but an infinitely improbable scenario. Other alternative is, it sounds like an attacker could "collision attack" the file server and upload a malicious file with the same md5sum.
It would make sense, if it had any relevance to the actual usage of md5sums=() in PKGBUILDs or clarified straight away the MD5 misconception that collisions don't actually apply here.
--Dettalk 19:23, 18 July 2015 (UTC) (last edit: 19:48, 18 July 2015 (UTC))
Initially I thought I wouldn't delete all the vulnerability info, but you're right, the sentence was ambiguous like that, so I've trimmed more details: I think that at least a link to Wikipedia:MD5#Security is needed, instead of mentioning "considerable vulnerabilities" in a generic way, and it should also help prevent others from re-expanding the topic in the future. — Kynikos (talk) 03:17, 19 July 2015 (UTC)
Lookgs good to me too :). Closing. --Dettalk 14:06, 19 July 2015 (UTC)