<gchristensen>
ghuntley: #nixos is a better place for that :) #nixos-dev is for generally higher level dev things, like long term work
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
<ghuntley>
thx gchristensen
orivej has quit [Ping timeout: 248 seconds]
yegortimoshenko has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<Mic92>
gchristensen: no problem. it did not hurry
orivej has quit [Ping timeout: 248 seconds]
yegortimoshenko has quit [Quit: WeeChat 2.0]
la_putin has joined #nixos-dev
goibhniu has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
FRidh has quit [Ping timeout: 248 seconds]
__Sander__ has joined #nixos-dev
FRidh has joined #nixos-dev
<peti>
domenkozar: ping?
<domenkozar>
pong
<domenkozar>
peti: ^^
ma27 has joined #nixos-dev
<peti>
domenkozar: We can play that game for a quite while. :-)
<domenkozar>
:D
<domenkozar>
peti: good, we're on the same page
<domenkozar>
I think all mappings should be in nixpkgs, as that moves fast compared to cabal2nix
<peti>
domenkozar: Yes, the mappings have to be in Nixpkgs, otherwise we cannot run recent versions of hackage2nix et al in older branches.
<peti>
domenkozar: Different branches might use different names for the same thing (in a way that we cannot guess automatically).
<domenkozar>
exactly :)
<domenkozar>
I wish we could just do pkgs.foo or null
<domenkozar>
so it either uses the mappings or fills in a null
<peti>
domenkozar: Well, we *could*. callPackage foo { claus = pkgs.claus or null; } is legal code, AFAIK.
<peti>
But it *is* somewhat ugly.
orivej has joined #nixos-dev
orivej has quit [Client Quit]
<peti>
domenkozar: What we should really do is have a meeting of all interested parties on a weekend and work on a well thought-out design for cabal2nix 3.0. There is too much cruft in the code. Some code is in cabal2nix but belongs into language-nix or distribution-nixpkgs, really. Other code exists but should arguably not part of cabal2nix at all, i.e. the whole "guess what an URL means" bit is very unpleasant.
<peti>
Last but not least, there's almost no regression testing.
<domenkozar>
this weekend won't work for me, but we can figure out the date
<peti>
Same here. This weekend would be a wee bit too spontaneous. :-)
<domenkozar>
what would be interesting to me is:
<domenkozar>
- have explicit fetchers
<domenkozar>
- add github fetcher
<domenkozar>
- map cabal files without information load
<domenkozar>
- saner nixpkgs resolving
<peti>
- use a text templating engine to create Nix expressions from ADTs so that default mode and shell mode become just two different representations of the same internal data.
<domenkozar>
peti: to replace Doc?
<peti>
domenkozar: Yes. Cabal2nix shouldn't hardcode the format it generates. Instead, users should be able to point it to some template Nix file and have it fill in the placeholders. Then people could generate whatever crazy output they'd like without having to modify the code.
<peti>
domenkozar: Arguably, we could even use Nix itself for this.
<peti>
I.e. cabal2nix write out a Nix dictionary that captures the contents of the Cabal file so that you can use Nix itself to generate whatever you want from it.
<domenkozar>
but it might not be enough
<peti>
domenkozar: The problem with 'here' is that it's resolved at compile-time AFAIK. I'd like to have a template engine that loads the template from disk, at run-time, so that users can easily edit and replace it.
<domenkozar>
ah ok :)
<domenkozar>
something to replace the need for separate user custom stuff, default and shell
<peti>
Exactly.
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 252 seconds]
FRidh has joined #nixos-dev
<gchristensen>
also, #nixos-aarch64 Mic92
ma27 has quit [Ping timeout: 255 seconds]
manveru has joined #nixos-dev
ma27 has joined #nixos-dev
ckauhaus has joined #nixos-dev
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
<domenkozar>
peti: maybe you can help me resolve the mistery
<domenkozar>
on two different machines, cabal2nix returns different sha256 for same package
<domenkozar>
using same cabal2nix version and same package/version
<domenkozar>
so cabal2nix is using some nix tooling and behaviour changed?
<domenkozar>
that can't be true, I have the same cabal2nix closure
<LnL>
yeah, probably
<domenkozar>
so it must be something impure
<LnL>
maybe a different version of nix-prefetch-url?
<domenkozar>
both machines use Nix 1.11.15
<domenkozar>
both are NixOS machines
<domenkozar>
ok, I'll dig in how sha is computed
<peti>
domenkozar: Try wiping ~/.cache/cabal2nix. Maybe that makes a difference?
<domenkozar>
oh that's a thing?
<peti>
domenkozar: Also, it makes a difference whether the machine running running cabal2nix has ~/.cabal/packages/hackage.haskell.org/00-index.tar or 01-index.tar (and in what version).
<domenkozar>
nope, still the same
<domenkozar>
aha!
<domenkozar>
let's see
<peti>
wai-middleware-prometheus-0.2.0 is a particularly evil package to access because it used to be broken in the 01 tarball until very recently.
<peti>
It maybe a good idea to wipe ~/.cabal/packages/hackage.haskell.org/*.* and run "cabal update" from scratch. (This was also announced on the Haskell mailing list recently).
<gchristensen>
there is a big fat archive of ~40GB of account and password combos being passed around the internet. I'd be shocked if some people with merge writes didn't have their passwords in this (or another) leak. would it be inappropriate to send an email to everyone (individually) asking the to rotate their creds, consider enabling 2FA on GitHub, and have a passphrase on their ssh keys?
<ckauhaus>
is there any way too look up my own e-mail address / commonly used nickname?
<ckauhaus>
don't want to download 40G ;-)
<gchristensen>
I could do it for you, and I could do it with `-q` so I wouldn't actually see the result, just a positive / negative match
<gchristensen>
(I really don't want to know your password X.X)
viric has joined #nixos-dev
<ckauhaus>
all of them randomly generated :-)
<gchristensen>
PM me if you'd like me to look anything up
<ckauhaus>
just wondering if it would be feasible to filter the list of NixOS maintainers this way
<gchristensen>
I think it could be done, that is a good idea
<ckauhaus>
then you could write a stronger message a la "your account is BROKEN"
<ckauhaus>
that would definitly be worth a mailing
<gchristensen>
it is slow, though, grepping through 40gb of data, user by user :)
<LnL>
gchristensen: was there a breach or something?
<LnL>
I have way to many generated passwords to search for every single one :p
<viric>
did someone check whether the file has correct passwords?
<gchristensen>
I have checked, viric
<viric>
good
<gchristensen>
it is 1.4B passwords correlated to accounts
<ckauhaus>
new idea: mail every maintainer to check himself/herself on the website
<ckauhaus>
*and* to set up 2FA and ssh passphrase in any case
<viric>
ssh passphrase is irrelevant to this, isn't it?
<viric>
how does that relate?
<ckauhaus>
in that specific case, probably yes
<ekleog>
gchristensen: oh, you have the recent indexed one, or the bunch-of-dumps-in-random-form-and-compression-level one?
<ckauhaus>
but it is a quite valuable general security measure
<gchristensen>
viric: it is not irrelevant, with password reuse it'd be easy to look up passwords matching accounts known to match you, and use that password against you. it depends on how valuable of a target you are, sure, but why have a password at all on your ssh key if you don't care about it
<pie_>
gchristensen, which database? >_>
<pie_>
would be nice to know to check if i have anything dumped
<viric>
gchristensen: but you should hold your ssh key file unreachable
<ekleog>
ckauhaus: I never understood why some people advocate ssh passphrases: if your computer is infected then you're dead anyway (privesc via alias sudo='evilsudo' then root looks into the process), and if it's not you're safe anyway (well, assuming you have full-disk encryption, but that's even more basic than ssh passphrase encryption?)
<gchristensen>
viric: then why have a password on your SSH key at all? defense in depth
<pie_>
ahh just a password list
<gchristensen>
having your computer compromised is not the same as your ssh key being compromised
<pie_>
wel...if you use your ssh key on a compromised computer
<ekleog>
is it not?
<gchristensen>
it is not
<ekleog>
if your single-user computer is compromised the attacker can just get into the ssh-agent
<ekleog>
(not speaking for multi-user computers here, as it's not a really widely-used setup for handling private keys)
<gchristensen>
yes, if your computer is compromised they can abuse your system and do what they want, but there are ways to leak your private key which don't involve your computer being compromised
<pie_>
(unrelated, i was going to say it might (?) be nice if the packages page had a reference to a github issue for a package? obviously there is a question of the liveness of a package, and packages that done have issues but eh..?)
<viric>
gchristensen: like what?
<pie_>
"There is about 38% of the list that is unique (with sort & uniq I get 384149228 lines).
<pie_>
And a lot are not only password but email:password"
<gchristensen>
like oops I copy-pasted my private key to you instead of my public key, or my backup USB disk wasn't encrypted like I thought, or I accidentally setup dropbox on ~ instead of ~/dropbox or, or, or
<viric>
I do have passphrase in my ssh keys, but I also run agents and use agent forwarding often
<gchristensen>
that is good, ssh agents are a good thing
<viric>
and I don't use agents for all my keys. Some of them I want always requiring password
<ekleog>
... agent forwarding is a good thing? the one that forwards your cleartext ssh key to the proxy?
<viric>
And I use ssh keys a lot, because I don't like sending my passwords
<viric>
ekleog: I don't use ssh-add remotely
<gchristensen>
agent forwarding doesn't forward your private key
<ekleog>
(also, gchristensen, indeed I get what you mean by use of ssh passphrase then, if you're speaking of user mistakes sending it out in cleartext)
<ekleog>
ok, it doesn't really forward your private key, it allows the remote to do whatever it wants with it
<gchristensen>
user mistakes are like way higher of a threat than being specifically targeted, it is important to guard against them
<ekleog>
“An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.” man ssh_config(5)
<gchristensen>
yes of course
<gchristensen>
I'm done with this particular conversation
<ekleog>
it's just as bad as forwarding your private key (and looks just wrong to me when ProxyJump and the like exist)
<gchristensen>
it is not as bad as forwarding your private key, full stop
<ekleog>
well, we just disagree on this one, but I'll continue using ProxyJump / ProxyPass instead of AgentForward :)
<niksnut>
ssh-add -A will cause the agent to prompt for permission for everyt use of the key, so the attacker cannot silently perform operations with the key
<ekleog>
as for user mistakes, I completely agree with you, but the loss in usability looks not worth the security added to me (then I'm used to qubes os that makes it really hard to inadvertently leak your private key, so ymmv)
<ekleog>
niksnut: hmm... I don't have a `-A`, neither in man ssh-add nor in man ssh-agent?
<gchristensen>
it must be pretty cool to be immune to mistakes worth protecting against
<ekleog>
niksnut: oh, you mean the -A of ssh, AgentForward? I must say I never even tried it, taking for given the man page saying basically not to use it, it's great if they added some security! :) (then I still don't see a use case for it not covered by the not-forwarding-anything ProxyJump, but I guess some bunkers are configured with AllowTcpForwarding=no?)
<ckauhaus>
didn't want to kick off a lengthy discussion about the merits of SSH passphrases... :-/
<gchristensen>
indeed >.>
<gchristensen>
I'll send some emails tonight
<ckauhaus>
grahamc: back to you original question: I think it would be reasonable to mail all maintainers, hinting them too the look-up site and suggesting 2FA and SSH passphrases
<gchristensen>
sounds good, thanks :)
<gchristensen>
also, maybe a project which monitors contributors to your github project for compromised creds
<ekleog>
yeah sorry to have triggered this way too :/
<fpletz>
vcunat: do you want to revert? I'm gonna look at it tomorrow or the day after
<vcunat>
Oh, thanks, I didn't notice.
<vcunat>
We haven't had an update of nix-unstable for six days, so perhaps better revert for now, unless it claims to fix something important and it's not a big rebuild.
<fpletz>
oh, yeah, better revert it then
<fpletz>
sorry, didn't notice that
<vcunat>
6 rebuilds only - should I do the revert or you want it?
<fpletz>
vcunat: I broke it, I revert it :) done
<vcunat>
I see. OK :-)
<vcunat>
Let me try again to force a channel bump...
<niksnut>
ekleog: sorry, meant ssh-add -c
<ekleog>
oh, nice one, thanks :)
Sonarpulse has joined #nixos-dev
phreedom has quit [Quit: No Ping reply in 180 seconds.]