justanotheruser has quit [Ping timeout: 265 seconds]
justanotheruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 276 seconds]
justanotheruser has joined #nixos-security
filemon has joined #nixos-security
lassulus has quit [Ping timeout: 240 seconds]
lassulus has joined #nixos-security
<filemon>
can someone fucking help me im playing runescape with an hacker from the usa/
filemon has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<gchristensen>
heh
<andi->
that is a weird one o.O
ckauhaus has joined #nixos-security
astrall33 has joined #nixos-security
<astrall33>
ahoy!
<ckauhaus>
hi
<ckauhaus>
currently merging a bunch of res' security PRs (which are excellent btw) into staging-19.09
<ckauhaus>
whom to trigger to merge staging-19.09 into release-19.09?
<astrall33>
broken.sh its lolz
<andi->
ckauhaus: I usually would like RMs to keep care of their releases even after the initial release.. since that has never really happened in my experience I tend to do the staging build on hydra, inspect it and then merge into the release branch once everything looks fine.
<andi->
astrall33: feedback welcome
<ckauhaus>
RM for 19.09 was sphalerite, right?
<andi->
and samuel
<andi->
disam on IRC
<ckauhaus>
good
<ckauhaus>
I'd really like if they would look after their branch till EOL... security is such a huge task that I'd rather keep out of the stabilizing business
<andi->
It really depends on the size of the rebuilds. If it just rebuilds a few thoussand light packages you shouldn't bother with staging
<ckauhaus>
sure
<andi->
if it touches the entire X, ssl, … ecosystem you might want to send to to staging
<ckauhaus>
but the rebuilds I'm currently looking at are 1000+
<ckauhaus>
staging-19.09 is a good idea for these
<andi->
that might be fine if they go in at the same time to the stable branch as hydra will execute them all together (ideally)
<andi->
With the staging branch you will also have to take care to merge in the real release branch before kicking off a hydra job as otherwise you might be building something nobody ever uses
<astrall33>
do nixos have 'the anonomous population contents (debra and ian)', so you can get metrics on this type of stuff?
<tilpner>
astrall33: Not in that way. The binary cache might keep access statistics, but I don't know that
<astrall33>
i guess you can can't derive that from git clone of nixpkgs, as it copies the entire set of packages.
<astrall33>
yeah, if you not using a cache build from a remote cache, then you have no way of knowing... interesting cunodrum.
<tilpner>
You can easily build a script that voluntarily reports derivations/outputs used in your system closure (or anything else) to some central location
<tilpner>
But of course without adoption that doesn't help you all that much
<astrall33>
i can easily buid anything i like, but i'm talking 'defaults' setup. Early in unix in histroy, unix would come uncofngured, and you had to configure *EVERYTHING*, not only did it make you learn the system so you could fix it yourself...
<astrall33>
hmmm. I keep that idea on the back burner.. metrics , which are reported rather than dervived from network data, are of much more value..
<astrall33>
anyway i'm swiching to guile. ;-)
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
__Sander__ has joined #nixos-security
astrall33 has quit [Ping timeout: 245 seconds]
ckauhaus has quit [Quit: WeeChat 2.6]
filemon has joined #nixos-security
filemon has quit [Quit: Going offline, see ya! (www.adiirc.com)]
__Sander__ has quit [Quit: Konversation terminated!]
astrall33 has joined #nixos-security
astrall33 has quit [Read error: Connection reset by peer]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
WilliButz has joined #nixos-security
WilliButz has quit [Changing host]
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Remote host closed the connection]
ris has joined #nixos-security
lassulus has quit [Read error: Connection reset by peer]
astrall33 has quit [Remote host closed the connection]
astrall33 has joined #nixos-security
astrall33 has quit [Quit: Leaving]
astrall33 has joined #nixos-security
astrall33 has quit [Quit: Leaving]
astrall33 has joined #nixos-security
<astrall33>
i quite like broken.sh
astrall33 has quit [Quit: Leaving]
astrall33 has joined #nixos-security
<andi->
now we just have to use the information and start fixing things :-)
<astrall33>
blimey.... probably better to write a new OS. ;-)
<astrall33>
i presume there is a way to list them in serverity...
<astrall33>
remote/local/userspace/prv escaation.. that stuff.
<andi->
could be done.. I've not yet spent much time on that since there are so many different ways they can be classified in regards to severity... If I wanted to keep the ability to search for that kind of stuff I'd have to translate that into the data model and update those fields over time... Definitly not complex ust something I'd like to avoid
<astrall33>
people like finding/reporting sec bugs...nobody likes to fix them, or has a budget to do so. Alas while i left.