<aszlig>
... because who would run proprietary software (if at all) without sandboxing? =)
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
<Mic92_>
aszlig: what kind of sandbox?
<Mic92_>
is it like nix-index + patchelf?
LightDiscord has joined #nixos-dev
<vcunat>
hmm, chromium tests are getting stuck on master
<vcunat>
I can reproduce that locally
<aszlig>
Mic92_: nah, doesn't have anything to do with patchelf, it's a runtime sandbox which constrains the program to its closure + runtimevars (like for example it uses the nix library to query the closure of path-likes such as LD_LIBRARY_PATH)
<aszlig>
so in general it could be used for anything, not just proprietary programs, i just happen to find proprietary programs extra-suspicious which is why i wrote that in the first place
<vcunat>
it always stucks right after making screenshot ‘sandbox_info.png’
<aszlig>
vcunat: what's the content of that screenshot?
<vcunat>
aszlig: where does the file appear?
<vcunat>
inside the qcow2 image?
<aszlig>
vcunat: nah, it should be on the host
<vcunat>
I see no *.ppm or *.png
<vcunat>
bisection points to 65.* -> 66.* most likely
<vcunat>
(I'd have to build chromium now :-/
pxc has joined #nixos-dev
<aszlig>
vcunat: most likely you need to do a sync... an alternative would be to comment out or remove all of the tests coming directly after the screenshot
<vcunat>
(04:45:16 PM) aszlig: ... and the test succeeds
<vcunat>
(04:45:28 PM) aszlig: but this is obviously just a workaround
<srhb>
Oh, did I lag out...
<vcunat>
they were direct messages between us
<srhb>
Ah :)
<srhb>
OK, nevermind me then!
<vcunat>
we should've done this in the open
<vcunat>
(04:46:29 PM) aszlig: i'm trying with sync window activation
<aszlig>
vcunat: ack
<aszlig>
it seems that there is a delay between window creation and location bar focus... i'm trying now whether i can circumvent this with ctrl+l
<aszlig>
hm... this is ridiculous... no succeess...
<aszlig>
waiting 20 seconds is really nuts
<srhb>
No kidding.
<MichaelRaskin>
Obviously, my PR to experiment with better GUI tests as Nixpkgs tests got closed as functionality duplication… (and debugging NixOS tests is a ‘Just No.’ given their overhead)
<vcunat>
I don't think that would be really noticeable in our tests.
<vcunat>
(especially if chromium needs a rebuild)
<vcunat>
... but if you can rid of the delay without too much pain :-)
<MichaelRaskin>
Well, no sane amount of wait doesn't guarantee lack of false failures whe Hydra is loaded, and an insane amount of wait means that you cannot debug the test locally when Chromium slightly changes the behaviour
<aszlig>
vcunat: well, given that my real life uptime is already too much... i'd go for a workaround now...
<vcunat>
sleep resets uptime?
<vcunat>
(it doesn't on my desktop)
<vcunat>
(actually, tested only on suspend-to-*RAM*)
<vcunat>
I'm looking forward to it. Hopefully we can bump nixos-unstable today.
<vcunat>
There's no other blocker ATM.
<aszlig>
trying the lowest possible sleep amount without being *too* low and pushing in a minute...
<aszlig>
pushed
<srhb>
\o/
<aszlig>
the delay seems to be around 3 to 4 seconds, so i used a sleep of 10 seconds just to be safe
<aszlig>
vcunat: hm... you're right... it shouldn't reset uptime, but who knows which OS i'm running on...
<aszlig>
vcunat: sometimes it behaves in really weird ways
<aszlig>
and my RAM doesn't seem to be ECC memory
<vcunat>
:-) 10 seconds probably aren't enough in real life.
<MichaelRaskin>
Seems too low for Hydra, yes
<aszlig>
well... if it isn't enough, we can still bump it to 3600 ;-)
<vcunat>
If you referred to me, I meant real-life sleep.
<vcunat>
The commit you pushed works fine for me locally.
<MichaelRaskin>
Better 3000. Rationale: a patch to Chromium test should not timeout on ofborg if Chromium is available from cache
<vcunat>
I haven't managed to make Hydra complete an evaluation yet since.
<vcunat>
:-)
<vcunat>
ah, evaluation is there, so we should know soon
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<vcunat>
Success! Let me re-test for 18.03, as it now happens there as well.
<srhb>
fwiw if it turns out to be not enough it looks like reusing the other window might in fact help (since we're waiting for the titlebar at least with ocr -- but it might be incidental)
<srhb>
Thanks for the workaround ^_^
<pstn>
matrix-synapse will get an update for gdpr compliacne soon. I'm wondering whether it would be a good idea to bump the major version up even in 18.03.
GlennS has quit [Remote host closed the connection]
<vcunat>
gdpr on this channel as well :-D
GlennS has joined #nixos-dev
<vcunat>
if it's an unobtrusive update, certainly
kgz has quit [Ping timeout: 265 seconds]
<pstn>
vcunat: Can't really get around it atm. I don't think it's going to be that bad. I just don't want to be the first to get sued :-D
<gchristensen>
do I need to do gdpr stuff for ofborg?
<MichaelRaskin>
Well, one could argue that you do your best to make sure that what ofborg stores (logs and outcomes) is independent of the identities of any people…
pie__ has joined #nixos-dev
<vcunat>
I don't expect there's anything special in ofborg.
<vcunat>
(but I don't have much idea about gdpr really)
<gchristensen>
how about the nixos cache
pie_ has quit [Ping timeout: 240 seconds]
<pstn>
I don't think there is any personal data in it, is there?
<MichaelRaskin>
If you run it as your own user and not as ofborg, it might leak $HOME
<gchristensen>
how does gdpr impact access logs?
kgz has joined #nixos-dev
<pstn>
gchristensen: You aren't allowed to just keep them and have to inform users that they exist. Pro tipp (at least for ipv4): Just logging the /24 net part is usually enough and not personal data.
<pstn>
In my company, we decided to do our access logging that way. We currently are in the process to find out what we do with ipv6...
<simpson>
gchristensen: I'm not a lawyer / this is not legal advice / GDPR PII / is anything which can deanonymize / Burma Shave
drakonis has joined #nixos-dev
<pstn>
simpson: I think it's "deanonymize without considerable effort", but that's the idea.
pie___ has joined #nixos-dev
<simpson>
pstn: I have personally been advised that IP addresses or any kind of geolocation is in scope for GDPR, so YMMV.
<vcunat>
uh, /24 is relatively good geoIP clue
<vcunat>
(I think)
<vcunat>
well, I hope it's extremely unlikely someone would try to "legally attack" a service like ofborg
<pstn>
simpson: That's what our legal people told us. That's the fun about gdpr: Nobody knows :-D
<simpson>
Indeed~
pie__ has quit [Ping timeout: 248 seconds]
<vcunat>
Yeah, not unusual with EU legislation to be a bit vague :-)
<gchristensen>
Im definitely of the "wait and see" opinion here...
<pstn>
I think /24 falls under the "statistical data" clause in the gdpr. IANAL of course.
<MichaelRaskin>
I do hope GDPR will only be abused in the obvious way
<pstn>
MichaelRaskin: In Germany, the obvious way are "Abmahntrolle" that use bots to wildly send case-and-desist letters and try to extort money. Currently trying not to be in the first wave of those...
<MichaelRaskin>
pstn: Mmm… bots and quasi-legal documents? One could hope they won't try to abuse GDPR, if only because they should be afraid their machinery can be found out of compliance
<pstn>
You can hope but they usually abuse every new law. It's all super shady and people use their licenses regularly but that doesn't stop them.
<MichaelRaskin>
Do they actually sue?
<vcunat>
I have yet to see a bot lawyer.
<pstn>
MichaelRaskin: Some times they do, some times they don't. You can attach fees to your cease-and-desist letters in Germany (if they ar legal in the first place) and that's how they usually cash in.
<pstn>
vcunat: If you want to get to know one, torrent some popular Music with a German IP.
<zybell>
GDPR:Is relatively simple:you split all personal info(login account,email,payment details...)from publically available personal info,which is strictly opt-in(profile,gravatar,nick)and all logs,tasks,gits(anonymous data until nick is posted).And you connect these machines by tokens,that are unique and do convey info about the owner only with the cooperation of the server one,where that info is deleted some fixed time (maybe 0)after the
<zybell>
token is redeemed.That policy is publicly posted,and presented in short when an account is created. In short you need a central place where that link with personal data can be made and *broken*.
<simpson>
zybell: Hypothetical: A user uploads an encrypted blob of PII to my storage service. I do not have the key and cannot tell that the blob contains PII. What does GDPR require me to do with this blob? AFAICT there's no allowance for this sort of provider-independent security.
LightDiscord has quit [Quit: Page closed]
<LnL>
add a hidden master key so you can help users identify their personal information
<zybell>
Simpson:there is:there is law that *forbids* you to even attempt to decrypt that data(even if it is as easy as pw protected zip)thanks to DRM.For you that is *legally* no PII.Unless you get the key to find out how rich the persons are ofc(AUFTRAGSDATENVERARBEITUNG);-)
<ekleog>
<obadz> ekleog: thx. I was just downloading a tarball :( <-- yeah, sometimes you just need to add a cargo.lock, last time I had to I just gist'd it for temporary use, and PR'd it and the commit was accepted
<ekleog>
the general policy for executables is supposed to be “please commit your Cargo.lock”, but it turns out quite a number of devs forget about it, and don't notice (as they have theirs locally)
<ekleog>
simpson: I don't think GDPR enforces against that, after all I can just upload a picture of cat and hold a vernam key that decrypts it into whatever same-length cleartext, including PII or top-secret documents :)
<zybell>
LnL:you can *allow* users to have a signature on their data,to allow *you* to help them find their data, but *never ever* do the key yourself.
<simpson>
zybell: LnL was being sarcastic, I think.
<zybell>
I wanted to make sure.
<LnL>
yeah, I wasn't serious :p
<zybell>
There is even a (complicated)situation where you *can* do it. And that may make sb believe they could it do in others.
<vcunat>
I've seen desires to encrypt IP addresses in logs to achieve pseudonymization.
<vcunat>
(but maybe it wasn't gdpr-related, though it was recent)
<zybell>
vcunat:that may be possible,if the keys are strictly managed.
<clever>
what about just hashing the ip?
<clever>
then you have no undo, but you can answer the question "did ip X contact you?"
<vcunat>
that's almost the same as encryption
<zybell>
The complicated situation is comparable to that vcunat alludes to.
<vcunat>
and it's worse on privacy in the forward direction, assuming the salt is missing or public
<vcunat>
(with 32-bit space you can brute force the hash in most cases)
<zybell>
clever no. hashing is *not* enough.
<zybell>
HMAC can be *made* to work.
<Mic92_>
there is also differential privacy
zybell has quit [Ping timeout: 260 seconds]
zybell has joined #nixos-dev
pie___ has quit [Ping timeout: 276 seconds]
pie_ has joined #nixos-dev
<sphalerite>
Are we getting glibc 2.28 in the near future?
<sphalerite>
oh er it's not released yet
<vcunat>
will something important be in there?
<vcunat>
> Nominative and genitive month names are now supported for the Catalan and Czech languages. :-)