NixOS Security Triage - Public Room Timeline

	NixOS Security Triage	747 Members
	Coordination and triage of security issues in nixpkgs	228 Servers

Load older messages

Sender	Message	Time
11 Jun 2021
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
Sandro	don't know about nix-env. Update everything?	12:21:11
Henson	Sandro: of course I know about nix-env to upgrade everything	12:21:43
Sandro	if you are not mixing channels or importing any other nixpkgs then you shouldn't be able to use an old version	12:21:46
Henson	Sandro: are my questions annoying you?	12:25:55
Sandro	nope	12:27:15
Sandro	* not at all	12:27:20
Sandro	I don't think we have anything to know if any stale package are used. You probably just want to upgrade everything and then garbage collect	12:27:48
Sandro	if the store path is still there then figure out what uses it	12:28:00
Henson	Sandro: ok	12:30:59
Henson	but say you've got a bunch of NixOS computers in production and you want to determine if they're vulnerable and only upgrade them if necessary, or perhaps only upgrade the vulnerable packages. I had a server that was used by people that was vulnerable to the sudo bug, but for certain reasons I couldn't upgrade the entire computer, so I did an overlay with just the sudo fix in it. I feel like there should be a way to do a security audit on a system to determine if it's vulnerable other than upgrading every package. I don't feel like this is an academic question, is it? Isn't determining if a system is vulnerable and only upgrading it if necessary (or perhaps only the vulnerable packages if possible) something that people do in practice?	14:18:48
andi-	Regarding the fix: use the git version that your channel is on. Same story as with random version suffixes: you still have to make a lookup to see in which one it is.	14:22:18
Sandro	only upgrade the vulnerable packages. Add a overlay with the change and rebuild a few hundred packages.	14:30:27
Sandro	I feel like there should be a way to do a security audit on a system to determine if it's vulnerable other than upgrading every package. One of the problems is that the data on vurnabilities is from time to time not that great. I think ImageMagick is a good example where CVEs regularly have wrong version ranges.	14:32:33
Henson	Sandro: yeah, it would vary based on how dependent other packages are on the thing being fixed. In my sudo case it was only one package, but I can see it just being more worth it to upgrade everything, especially if your change makes it so you can't fetch from the binary cache.	14:33:09
Sandro	Isn't determining if a system is vulnerable and only upgrading it if necessary (or perhaps only the vulnerable packages if possible) something that people do in practice? Maybe in some enterprisy environment. I am just riding the latest and greatest on all machines.	14:33:58
Sandro	redhats rpm has a feature where you can upgrade all packages that belong into a CVE. Problem with that is when the CVE data is not perfect you might miss something and it also encourages to stay on some stone age old version because we do not have the CVE.	14:35:10
Sandro	In reply to @henson:matrix.org Sandro: yeah, it would vary based on how dependent other packages are on the thing being fixed. In my sudo case it was only one package, but I can see it just being more worth it to upgrade everything, especially if your change makes it so you can't fetch from the binary cache. if you are using the stable release such security patches get normally backported and then you should be able to use the binary cache.	14:36:02
Sandro	but I am personal normally on unstable and for packages on master so upgrading everything is just easier and saves me time.	14:36:41

Show newer messages

Back to Room ListRoom Version: 6