<hexa->
uh yeah, we kinda need to tackle some major issues there :<
hexa- has quit [Quit: WeeChat 2.9]
hexa- has joined #nixos-security
aminechikhaoui6 is now known as aminechikhaoui
justan0theruser has quit [Ping timeout: 265 seconds]
<andi->
Thought: I'd like to mark all binaries that we package and distribute (steam, electron, slack, ...) as insecure / binary distributions so that I can prohibit them from being installed on my machine as I can never verify the binary that I am receiving (And I don't want any of that crap in my closures).
<Foxboron>
Are they not named "$pkgname-bin"?
<andi->
You wish...
<Foxboron>
Arch has discussed dropping such binaries into a different repository. But that seems a bit debian-esque if you consider firmware drivers and other opaque blobs
<andi->
There are some blobs that can't be produced by the general public (like firmware, ...) and that is (for the moment) "fine".
<andi->
but we package for example Apache Directory Studio which is just an unzipped tarball with patchelf applied.
<andi->
The actual java code and binaries in there are from somewhere..
<andi->
(somewhere being the official release distribution)
<supersandro2000>
java infra is just not great and so building from source there is not an easy option
<andi->
I know that yet I would prefer if I could distinguish between those packages that I can actually properly reproduce and those that are just binaries from somewhere
<supersandro2000>
that wont probably work either because not all packages are deterministically rebuildable
<Foxboron>
It's progress towards that point though
<hexa->
eh
<hexa->
just suffix with -bin if its not a source build
<hexa->
we're not asking for more rn
<supersandro2000>
I'd rather add an extra variable where we can also specify unstable
andi^ has joined #nixos-security
<supersandro2000>
adding suffixes to pname will break things
<supersandro2000>
or better throw binary download or unstable into meta
<Foxboron>
supersandro2000: They are still opaque binaries. If the source is available there is no good reason to not package it properly.
<supersandro2000>
that does not help with reproducible
<supersandro2000>
building from source likely introduces new unreproducible things
<Foxboron>
So you'd rather have opaque binaries?
<supersandro2000>
no
<supersandro2000>
reproducible just has nothing to do with labeling binary downloads
<andi^>
Sure we can always reproduce a null-op on a downloaded binary and it will always reproduce but what we (I assume the majority of RBuilds people here) want is to produce the same binaries from source of a F/OSS package.
<Foxboron>
I'm just saying it's progress towards that goal
<supersandro2000>
yeah sure go ahead and convert them but for most jar downloaded the not great ecosystem around it stopped people from doing it
<andi^>
Software freedom for me means that I can decide to not have those on my machines unless I accept each and every transitive case explicitly.
<supersandro2000>
yeah sure. Just do some RFC to add a meta.downloadedBinary or something and add that to all binary downloads
<hexa->
supersandro2000: so how do i address firefox and firefox-bin, when pname is firefox for both and only the meta is different?
<supersandro2000>
hexa-: there are two packages for that
<supersandro2000>
but renaming a package if there is only one does not help anyone
<hexa->
it would help andi?
<andi^>
I really don't care about package names. I'd like to forbid any kind of binary packages except for those whitelisted.
<andi^>
err permitted not whitelissted. Sorry, do not mean to offend anyone.
<hexa->
fair
andi^ is now known as andi-
cole-h has joined #nixos-security
<supersandro2000>
and it would break at least half of those packages
<supersandro2000>
because people tend to use pname all over the place
<supersandro2000>
and filtering packages by their pname which could change is also not an ideal solution
rajivr has quit [Quit: Connection closed for inactivity]
<andi->
pname is a terrible concept. We still don't have a proper field to record the actual name of a package. If my would be called "Super Duper Package" someone would call it superDuperPackage or similar (either the attribute or the pname). We should instead record the correct name of a package somewhere.
<andi->
gchristensen: that isn't even funny. I had that argument ever since it first came up but back then it was just rushed through instead of doing a proper RFC on it...
<gchristensen>
:|
<eyJhb>
andi-: Isn't it in the metadata?
<andi->
eyJhb: for almost no package. It is automatically taken from .name if I recall correctly
<andi->
nix-repl> firefox.meta.name
<andi->
"firefox-unwrapped-85.0.2"
<andi->
no :)
<eyJhb>
*time for another treewide :D
<eyJhb>
andi-: Oh you're right. That is horrible.
<eyJhb>
Throwing it out there, would it be insane to put it in metadata?
<andi->
It is just that we could have used the pname momentum to "do it right" and generate whatever we have as pname (that is only relevant for store paths anyway/except for python packages...) as input to some function that generates store path compatible names.
<andi->
e.g. we could write nix code that translates pname = "Apache Directory Studio"; to name = "ApacheDirectoryStudio-${version}";
<eyJhb>
True, that would have been cool
<eyJhb>
But I guess there might be MANY weird names?
<andi->
That is the point of having them. The unique name that the software actually has!
<andi->
In the right spelling and right letter casing.
<andi->
And to get back to the topic here: And then use that to match those better against CPEs (not that it would be a lot better...)
<eyJhb>
Thinking more of -._!æåø names
zgrep has quit [Quit: No Ping reply in 180 seconds.]
{^_^} has quit [Remote host closed the connection]
V has quit [Remote host closed the connection]
jpo_ has joined #nixos-security
edef has joined #nixos-security
asymmetric_ has joined #nixos-security
<andi->
just remove anything that isn't a-zA-Z0-9 for the store path
lejonet1 has joined #nixos-security
edef is now known as Guest63305
Guest63305 has quit [Killed (rothfuss.freenode.net (Nickname regained by services))]