| 11 Jun 2021 |
 Synthetica | Not everything uses channels in that way | 11:41:16 |
 Sandro | then you are fetching some package with a git hash | 11:41:28 |
| Sandro | does not work when you fetch master directly from a git repo | 11:42:28 |
| Sandro | but when you are using flakes or niv then it works again | 11:42:42 |
 Henson | is that better than denoting the patch level using a version string change or something like that? | 11:45:08 |
| Sandro | So you want to start version numbers like debian has? | 11:45:47 |
| Sandro | I am not looking forward to things like 2.0.0+really1.16.0-2ubuntu2 | 11:47:08 |
| Henson | I don't know. I've used Debian for decades and I'm familiar with it so that's where that idea is coming from. Changing the version name would require somebody to remember to do it, whereas checking the channel hash wouldn't. But checking the channel hash is more difficult than just checking to see what version string is in the package name in the nix store | 11:47:13 |
| Henson | Sandro: yeah, that does get a little ridiculous | 11:47:25 |
| Synthetica | I'm not sure that isn't preferable to the current situation where 1.15.1 is vulnerable but 1.15.1 isn't. | 11:48:17 |
| Sandro | nix is smarter than apt with its versions. We don't need such crazy version numbers. | 11:49:20 |
| Henson | Sandro: and the name wouldn't have to be really long like that, either. Something like a simple integer increment like 0.118-p3 would be sufficient for someone to tell if it was pre or post fix | 11:50:11 |
| Henson | but that would mess things up if you were trying to merge multiple patches together, or put the patch into different locations in the source tree that have different patch numbers. Then you'd get ambiguous patch level numbers where p3 in one branch would be different than p3 in another branch | 11:51:59 |
 pennae | include the hash of each patch in metadata somewhere? 🤔 | 11:54:26 |
| Synthetica | meta.securitypatches | 11:54:54 |
| Synthetica | I kinda like it 🤔 | 11:55:01 |
| Sandro | we don't need new metadata | 11:56:30 |
| Synthetica | I suppose you could also parse .patches somehow | 11:57:01 |
| Sandro | In reply to @henson:matrix.org
but that would mess things up if you were trying to merge multiple patches together, or put the patch into different locations in the source tree that have different patch numbers. Then you'd get ambiguous patch level numbers where p3 in one branch would be different than p3 in another branch that sounds like a you problem then | 11:57:05 |
| Sandro | In reply to @synthetica:matrix.org
I suppose you could also parse .patches somehow yeah | 11:57:09 |
 philipp | In reply to @sandro:supersandro.de
that sounds like a you problem then Rude! | 11:58:02 |
| Sandro | nix-channels are identified by git hashes. If you are merging them around then they are broken. Rebase your forks to prevent that. | 12:02:21 |
| Sandro | I don't believe that adding more metadata that needs to be maintained solves the problem in a maintainable way | 12:04:18 |
| Sandro | In reply to @sandro:supersandro.de
nix-channels are identified by git hashes. If you are merging them around then they are broken. Rebase your forks to prevent that. *advancement of the channels | 12:10:45 |
| Sandro | we don't have version numbers for packages and you can't say you need at least hash X, so we need to use git hashes to know if something is already patched | 12:11:17 |
| Sandro | if you break them via a 3 way merge you would need to look at the actual file if you have the patch | 12:11:34 |
| Sandro | We could also track all the CVEs fixed in any package version but who is going to maintain that data? It is only useful if you know that the data is right. | 12:15:25 |
| Henson | Sandro: I'm starting to see the benefit of your original suggestion. Tracing the package to a channel and then if that's pre or post fix allows you to answer the question of "is my package vulnerable" without version numbering or meta data, and in a way that doesn't cause any merging problems regardless of where the fix enters the source tree. | 12:17:45 |
| Henson | Sandro: but what if a particular package is stale relative to your channel. If you update your nix channel but don't upgrade any of your packages, or if a new package uses an old package as a dependency, then your user's channel hash will not tell you whether a particular package came from that channel. | 12:18:58 |
| Sandro | you ofcourse need to rebuild your configuration for it to take affect | 12:21:01 |
