| 11 Jun 2021 |
 Linux Hackerman | Pretty sure there are many other ways to get root via polkit :) | 08:24:22 |
 Henson | because the fix for the polkit bug (https://github.com/NixOS/nixpkgs/pull/125554) is in the form of a patch without any change to the package version string, is there any way for someone to tell whether a particular system has this fix or not? | 11:30:54 |
 pennae | you could check the package version and the store hash that provides the running polkit | 11:32:44 |
| Henson | but the package version will just be 0.118 both with and without the fix, right? | 11:34:11 |
 Synthetica | we should really have a canonical way of denoting security patches | 11:35:24 |
| pennae | Henson: yeah, but the store hash will be different (and only one of them will be vulnerable) | 11:35:46 |
| pennae | would be better to have a marker though | 11:35:58 |
| Henson | pennae: yes, to tell from the store hash you'd have to download a known fixed version and compare the hash. And if they're different, that doesn't necessarily mean the other one is vulnerable, as the store hash could change based on some other non-patch-related build dependency of polkit | 11:37:20 |
| pennae | true, that way you can only really identify something that is for-sure broken | 11:39:00 |
 Sandro | I have a better idea:
cat /nix/var/nix/profiles/per-user/$USER/channels/nixos/.version-suffix | cut -d. -f2 and then check if that short hash includes the commit you need
| 11:40:28 |
| Sandro | pretty easy and uses existing stuff we already have | 11:40:47 |
| 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 |
