manual: document ways of obtaining source hashes #53785
Conversation
... and security nuances
|
Rendered with state as of 663b8cc
|
doc/coding-conventions.xml
Outdated
| </para> | ||
| <para> | ||
| This works well when you've upgraded existing package version and want to | ||
| find out new hash, but is useless if package doesn't have top-level |
There was a problem hiding this comment.
It's not so much a question of top-level attribute, as of being accessible via an attribute path.
| </itemizedlist> | ||
|
|
||
| <section xml:id="sec-source-hashes-security"> | ||
| <title>Obtaining hashes securely</title> |
There was a problem hiding this comment.
Maybe note that the threat model discussed here is MITM close to the developer's network?
Whatever you do, MITM close to the server side (or a succesful server intruder) can even get a «valid» certificate via DV…
|
Technically speaking, there is a one more crazy-ish way of obtaining hashes that I sometimes use: fake hashes + Ctrl-c + copy the URL from the progress output + This way I do get the exact URL for free, but TLS is checked and the file is only downloaded once. |
|
By the way, does git verify correctness of revision hashes by default? Does |
doc/coding-conventions.xml
Outdated
| A little nuance is that <literal>nix-prefetch-*</literal> tools produce | ||
| hash encoded with <literal>base32</literal>, but upstream usually provides | ||
| hexadecimal (<literal>base16</literal>) encoding. Fetchers understand both | ||
| formats. Nixpkgs doesn't stadartize on any one format. |
There was a problem hiding this comment.
| formats. Nixpkgs doesn't stadartize on any one format. | |
| formats. Nixpkgs does not standardize on any one format. |
|
Thanks! |
... and security nuances.
Related: #53754
cc @7c6f434c @grahamc