<pie_>
so, you cant read everything in your package manager but can anything be done so that you dont need to?
<pie_>
id guess no you cant really do anythig about it xD
<LnL>
because of the way nix works everything related to secrets happens outside of builds
<LnL>
I don't think hydra even interacts with the signing keys directly
<pie_>
sure i was thinking generally though
<pie_>
lets say someone already has access
<LnL>
and if it's possible to access that somehow it's a software bug not a configuration error
<LnL>
ah
<pie_>
or whatever
<pie_>
i mean sure theres several different problems that could be tabletoped
<pie_>
(probably)
<LnL>
my best answer there is that there are a decent number of people that follow the git log pretty closely
<LnL>
there's a pretty good chance that something weird wouldn't go unnoticed
<gchristensen>
yeah
<pie_>
so who wants to give it a test?
<LnL>
I've gotten comments from people on reverted commits where I forgot to add an explanation for example
kalbasit is now known as kalbasit[m]
<andi->
I think commits to the repo are always a threat and as you already said will probably be noticed. There is enough people around most of the time that can revert them. The risk is still there tho.. What happens if someones credentials are being used for lets say a glibc upgrade with that strange way we do patches there and sneaks in a few extra bits... The way I see it the biggest threat for this kind
<andi->
of things these days is things like installing random npm, pypi, hackage, ... packages that export your keys. We've seen that with pypi and npm already (multiple times?). The think I would wish for would be proper 2nd factor auth whenever you merge and push something to nixpkgs (nix, …).
<pie_>
im not a huge fan of 2 factor auth that depends on 3rd party services that force me to tie my phone to it and such
<pie_>
ive never actually used any, but ive never been in a position it would matter
<pie_>
mainly privacy reasons
<pie_>
but also my dad doesnt use a phone and i just got screwed over by needing to replace his computer and gmail was asking to tie a phone to it when i tried to log in for him...
<pie_>
which just feels like a data grab tbh because i dont think i attached any sort of phone to it
<andi->
I see your point. I also dislike tieing everything to the phone. Hardware tokens might be better. Then the question arises which of those can you trust.. I wouldn't use a yubikey for example etc... I was just saying how one could counter that.. or at least try to raise the bar.
<gchristensen>
why not?
<pie_>
i think one of the last times this came up someone raised the point that phone is a separate network
<pie_>
well i mean if your machine is compromised your phone is still likely not to be?
<pie_>
"against who"
<gchristensen>
why not a yubikey?
<pie_>
*i dont actually know how a yubikey works
<andi->
I have a bad feeling... I know they have a good reputation. They work despite the recent infineon issue. They were straight with admitting issues and replacing devices... Still it is some closed source thing happening in there. Theoretically (more likely then other things at least) one could know the secret on that thing by knowing which serial my device has.. But that would be state level actor and
<andi->
well then it is game over anyway...
<andi->
Call me paranoid..
<gchristensen>
you're paranoid
<andi->
Well why do people order nitrokeys instead of yubikeys these days? ;-)
<pie_>
marketing?
<pie_>
idk :D never heard of them
<gchristensen>
longer gpg keys
<andi->
I've to admit we have to talk about solutions that could work for the project.. Being paranoid as I am doesn't help much there.
<andi->
Thats exactly why I bought mine back then..
<andi->
and I can read the code and have a open schematic etc..
<pie_>
arguably they could manufacture it evilly and you would have no way to verify
<pie_>
unless youre equipped for that
<andi->
yes
<andi->
but thast the generic argument you can always use.
<pie_>
i havent looked into it but i feel like the best thing would be to implement it in software on generic hardware
<andi->
You have to at least trust SOME hardware out there unless you want to solder it yourself.
<pie_>
so like an fpga or something
<pie_>
*this is a just so idea that i asspulled and have no idea how well it could actually work
<pie_>
lol, so we went from software supply chain attacks to hardware ones :p
kalbasit has joined #nixos-security
<gchristensen>
that is not true, pie_
<gchristensen>
the nitrokey and yubikey and related hardware have processors which contain the key material and won't let it out under any circumstances, are resilient to tampering, and will destroy the data if they're mucked with
<gchristensen>
implementing with generic hw makes it much worse
<pie_>
hm
<andi->
thats why "normal" computers come with TPMs that try to be a secure element within the standard hardware with software thing you described.
<pie_>
well sure but thats kind of missing the point if one argues precisely that the secure element is compromised?
<pie_>
ofc the question is how plausible is that
<andi->
Most people agree to some degree that they must assume the TPM/chip on the smartcard is okay.
<gchristensen>
not very
<pie_>
right
<pie_>
theres probably bigger issues first
<gchristensen>
like
<pie_>
...probably? :P
<gchristensen>
every line of your C code is a bigger issue than the secure chip in your 2fa device
<pie_>
well dont code it in c
<gchristensen>
every line of your OS's C code is a bigger issue than the secure chip in your 2fa device
<andi->
what kernel are you running? ;-)
<gchristensen>
your help desk is a bigger issue
<pie_>
ok good point
<gchristensen>
your telecom's help desk
<gchristensen>
your wifi, or your ethernet for your home
<pie_>
but thats also an argument for not using a yubikey?
<gchristensen>
no, it isn't
<andi->
no
<gchristensen>
it means use more hardware 2fa
<pie_>
ok i think i got a tiny bit mixed up
<pie_>
sure, that all makes sense
<andi->
Whilst I said I wouldn't use a yubikey (I do have them...) the best 2F is the one you have.
<gchristensen>
+1
<andi->
Even if it must be an SMS thingy..
kalbasit has quit [Quit: WeeChat 2.1]
<andi->
Which is bad but better then nothing
<pie_>
i was more rambling about software vs hardware implementation, the security of the OS is orthogonal to that?
<andi->
raises the bar of an attacker to also infiltrate the phone/be in proximity/...
<pie_>
yeah
<pie_>
ive never used this apparmor/whatever stuff, i wonder if we could reasonably autoderive rules for it with nix
<andi->
doubt it without further information from whoever packages things.
<pie_>
i figured ¯\_(ツ)_/¯
<andi->
An interesting approach in this direction is the unveil(2) and pledge(2) system calls. It lets the description of expected behaviour live within the source of the program. Sure it doesn't protect against malicious code authors but against issues being exploited to gain privs on a system.
<pie_>
yeah
<pie_>
mumble mumble openbsd
<pie_>
can we just do nixobsd? thanks. :P
<andi->
Actually.. I wanted to attempt that at some time.. seeing how little time I have right now that wont happen befor 2055 when I can finally retire..
<pie_>
yeah :c
<pie_>
i did a little reasearch on it but usually i dont have much of a clue about anything, i kind of ended up figuring nix likely depends on a lot of linux specific features that would preclude any trivial port?
<pie_>
same for nixpkgs..
<andi->
it runs on darwin ;-)
<pie_>
though maybe writing a separate nixpkgs for obsd might not be an utterly horrible thing, idk
<pie_>
re: nontrivial port, are there any key features that would make it impossible?
<pie_>
andi-, oh right, i forgot about that
<pie_>
well, thats something. but id dare guess they are very diverent at this point :p
<pie_>
"seeing how little time I have right now that wont happen befor 2055 when I can finally retire.." story of my life though :p
<andi->
My homeoffice days ar eusually a good thing to get a few hours of other work out of my body. So I am trying to increase that.
kalbasit has joined #nixos-security
kalbasit has quit [Quit: WeeChat 2.1]
kalbasit has joined #nixos-security
kalbasit has quit [Client Quit]
<andi->
while we are talking of tokens: anyone seen a hardware device that supports ed25519 yet?