<pie_>
something about channel authentication, downgrade detection, "authenticating arbitrary git repos" (?), "Another important change from a security perspective that we’re proud of is the reduction of binary seeds to 60 MiB on x86_64 and i686, thanks to tireless work on GNU Mes, Gash, and related software.", "On the same security theme, the build daemon and origin programming interface now accept new cryptographic hash functions (in
<pie_>
particular SHA-3 and BLAKE2s) for “fixed-output derivations”—so far we were unconditionally using SHA256 hashes for source code."
<lukegb>
pie_: the "arbitrary" part of "authenticating arbitrary git repos" is "where every commit to the git repo is gpg-signed"
<lukegb>
it's neat though, it checks commit N-1 for a .guix-authorizations file that contains commit N's signing key
<pie_>
ok i figured something like that @ pgp auth, i think git also has some verification stuff built in, i would imagine they base off that, but its nice that they built it into the system
red[evilred] has joined #nixos-security
<red[evilred]>
heh, my automation is broken somehow
<red[evilred]>
that'll learn me for not sanitizing my inputs ;-)
tilpner_ has joined #nixos-security
tilpner has quit [Remote host closed the connection]
<red[evilred]>
found it I think
tilpner_ is now known as tilpner
<red[evilred]>
apparently 2090 is problematic: CVE-2090-13584
<red[evilred]>
;-)
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 246 seconds]
pie_ has joined #nixos-security
<andi->
I like how guix manages to write release notes for their package manager :)
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-security
lassulus has quit [Ping timeout: 256 seconds]
lassulus has joined #nixos-security
justanotheruser has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-security
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-security
red[evilred] has joined #nixos-security
<red[evilred]>
Well, apparently vcunat thinks I was trying to get something past him. Oh well, RIP that relationship :-/
<red[evilred]>
le sigh
<red[evilred]>
back to work
<gchristensen>
I doubt it
<red[evilred]>
I hope you're right. I just forgot to tag something...
<red[evilred]>
I'm probably just reading too much into it - his point is fair tho.
<gchristensen>
he's surely not going to judge you in to oblivion
<red[evilred]>
Good 'nuff
<red[evilred]>
you haveing a good day thus far?
<gchristensen>
ehhh it is a day :P
<gchristensen>
wishing I had a whole team of people! you?
<red[evilred]>
I keep telling myself only 4-6 months to normalcy
<red[evilred]>
I need to find a way to parse nixexpr in some way
<red[evilred]>
so I can extract the list of patches so I can know if patches have already been applied
<red[evilred]>
I can't think of an example right now, but when I find a vuln like in zip - repology tells me that version 3.0 is the highest version and what we're currently set at.
<red[evilred]>
checking for whether there's a patch that's named after the cve would help speed things up
<red[evilred]>
anyways - bbiab - going to put some time into this vuln queue and see what I can find.
<hexa->
how do we handle security for webkitgtk on 20.09?
<hexa->
i'm inclined to update it from 2.28.4 -> 2.30.3
<red[evilred]>
I'm scared to ask about the dependency tree on that one
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
<red[evilred]>
Okay - policy question
<red[evilred]>
We have a library
<red[evilred]>
botan
<red[evilred]>
(1)
<red[evilred]>
with 5 CVEs
<red[evilred]>
1.10 series
<red[evilred]>
there's a 1.11.x series that will fix 4 of the 5
<red[evilred]>
but there is no way to fix the last one (which is of course the nastiest)
<red[evilred]>
unless the user moves to 2.x
<simpson>
Since the major versions are different, I'm guessing that it's a non-trival port?
<red[evilred]>
right
<red[evilred]>
its unfixable
<red[evilred]>
because - in the words of the project themselves:
<red[evilred]>
"Until 2.15.0 there was no API to access these alternative name DNs so it is unlikely that any application would make incorrect access control decisions on the basis of an incorrect DN"
<red[evilred]>
So...
<red[evilred]>
that "unlikely" is the key word
<red[evilred]>
they didn't say "won't"
<simpson>
So you're probably thinking of both packaging the 2.x series and also bumping the 1.x series to 1.11.x, because that represents a maximum of options for downstream packages and because fixing 4/5 is pretty decent.
<red[evilred]>
2.x is already packaged as botan2
<red[evilred]>
and agreed
<red[evilred]>
I'll push that to master
<red[evilred]>
for 20.09 - is a move from 1.10.x to 1.11.x acceptable or am I going to be pulling patches?
<red[evilred]>
because that;s a long way to go
<gchristensen>
seems fine to e
<gchristensen>
how much dependn on 1.x?
<red[evilred]>
I don't know
<red[evilred]>
what's the nix command to list all packages that depend on another?
<gchristensen>
just monotone, from a simple grep
<red[evilred]>
wait - is there not a cli tool for navigating / querying the dependency tree in nixpkgs?
<red[evilred]>
Oh - this is not awesome
<red[evilred]>
it looks like the 1.11 branch is the dev version
<red[evilred]>
and 1.10 was stable
<red[evilred]>
so 1.11 may have been what changed the API and got promoted to 2.x
<red[evilred]>
I'm reading the changelogs to verify
<red[evilred]>
"Botan 1.10.X is supported for security patches until 2017-12-31" (from the changelog)
<red[evilred]>
This may be one of those candidate packages for using the vulnerabilty metadata
<red[evilred]>
where it throws an error on compilation unless you specifically accept the CVEs in your configuration
<IdleBot_4fae1f80>
I wonder if things covered by CVEs are even used by Monotone… it is annoying that there is still no better VCS (have not looked at Pijul reboot yet)
<red[evilred]>
I don't know
<red[evilred]>
but since we have... many open vulns
<red[evilred]>
a way to prioritize against number of downstream packages might be a useful metric
<hexa->
I deleted the last monotone repo when dn42 moved to git in 2018 ish :D
<hexa->
haha
<IdleBot_4fae1f80>
I cannot say there are any changes I was waiting for in Monotone. it is just a thing done right. Well, OK, lack of migration from SHA-1 would be disappointing if «clearly not dead» Git would have completed the same by now
ris has joined #nixos-security
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
rajivr has quit [Quit: Connection closed for inactivity]