601 karma · joined March 24, 2011
> i milanesi hanno percorso in media 18,6 miglia
> in bici per andare al lavoro...
> velocità media a Milano 14,8 miglia all’ora
"The Milanese cyclist averages 18.7 miles per day to go to work... at an average speed of 14.8 mph". Is my translation okay? That seems improbable [time & distance, not speed]: the _average_ Milanese cyclo-commuter takes over an hour each way? Currently 36C/97F in Milan.Or is this per week? Is it current to talk in "miglia" in modern Italian? (though even km would be high IMHO).
It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading colons, adjacent colons).
This de facto standard becomes a little more obvious when one considers a likely implementation (iterating over "strchr(arg, ':')" or whatever). Any of these sequences then will give up an empty string:
PATH=:/foo
PATH=/foo:
PATH=/foo::/bar
And an empty string is equivalent to dot for chdir(2). zwp:/tmp$ cd ''
zwp:/tmp$ pwd
/tmp
zwp:/tmp$
(This is not the same as plain "cd" (ie with no args), which is a special case that takes you $HOME, of course).I agree it's surprising and potentially dangerous.
FWIW, the execp() functions hide a similar wtf. From the Linux man page:
The file is sought in the colon-separated list of
directory pathnames specified in the PATH envi‐
ronment variable. If this variable isn't defined,
the path list defaults to the current directory
followed by the list of directories returned by
confstr(_CS_PATH).
Security conscious programs that clear the environment and then call eg execlp() end up searching dot before the system path. Yay.Do you have a strong reason to prefer "set" over shebang flags? I have a slight preference for shebang flags so I can deliberately override them from the command line (but it's not a hill I'd die on):
$ cat foo
#!/bin/bash -eu
cd /nowhere
echo 'still here'
$ ./foo
./foo: line 2: cd: nowhere: No such file or directory
$ bash -c ./foo # thinking about system(3)
./foo: line 2: cd: nowhere: No such file or directory
$ bash +e ./foo # override
./foo: line 2: cd: nowhere: No such file or directory
still here
$
EDIT: Google's shell style guide has "Executables must start with #!/bin/bash and a minimum number of flags. Use set to set shell options so that calling your script as bash <script_name> does not break its functionality."https://google.github.io/styleguide/shell.xml?showone=Which_...
#!/bin/ksh -p
# ...
cmd=`basename $0`
$cmd "$@"
I just noticed that the what(1)-string (I haven't seen on of those for a long time) references "alias.sh", perhaps this is a clue? #ident "@(#)alias.sh 1.2 00/02/15 SMI"
Were builtins actually aliases in an early shell? I still don't understand how this works though.The googlable nugget is actually "organizational scar tissue" (it caught my attention too). It's from Jason Fried. On twitter:
https://twitter.com/jasonfried/status/2758624714
and also apparently in "Rework", quoted with more context here:
https://www.goodreads.com/quotes/1012423-policies-are-organi...
https://github.com/dspinellis/unix-history-repo/blob/Researc...
I'm not familiar with seals used on voting machines but that's common in other "tamperproof container" scenarios.
"He used $10 of ingredients you could buy, and whipped up his gummy fingers in the equivalent of a home kitchen. And he defeated eleven different commercial fingerprint readers, with both optical and capacitive sensors, and some with "live finger detection" features."
That article's a little old now and the tech may well have improved since but I wouldn't put too much faith in fingerprint readers. (Also: other attack vectors exist).
Check out the "yes"es in the "fixed" column in comment at https://bugs.python.org/msg85966
~1000 commits since I last looked at firejail, keep up the good work!
Yes. The first line of the article ("a SUID program that reduces the risk of security breaches") should be enough to raise a quizical eyebrow from security-minded users but overwhelming positive commentary I've seen elsewhere (lwn?) has not mentioned this.
Some of the obvious holes (eg "mount a tmpdir on any mount point") have now apparently been closed but I haven't been back to it for a while. Early releases did everything euid==0... It certainly needs more pairs of eyes.
OTOH the largest attack surface presented by a typical single-user Linux box is probably the browser and not an unprivileged local user looking for escalations (assuming: firejail drops privs perfectly and an attacker cannot trigger a vulnerability in SUID firejail from the application that it invoked). So could be that's a reasonable trade off for some folks.
> like the idea though
I agree, the feature set is nice but it needs some more basic TLC. "Security products do not necessarily make systems more secure" </rant>
1. BigCo pillages (resells) your data and/or puts compute (search) pressure on your db.
2. Data entry, triage. Is the plan (for plex) to source data solely from origins with an API?
Good luck, gute Reise :)
Assuming it's not all carefully orchestrated or multiple correspondents or...
https://github.com/rubygems/rubygems.org/commit/1067ab7e0871...
Cause: a "full name" is a dash-seperated join of its components, yet those components may themselves contain dashes :(
Rachel, could you write a small sneaky program (using eg libpcap) to see if the TCP handshake has completed by the time connect(2) returns control to your program, before your first write(2)?
Oops? Ironically (assuming two distinct values of PATTERN) I think you just answered your own question. (They are different: first is disjunction of patterns, second is conjunction).
Your point has merit for scripts (performance) but for data exploration at the prompt it's almost always irrelevant: the simplicity of pipe composition outweighs anything else.
A more experienced colleague: "Pah, that's just a crutch". Well, yes. And?
My personal tipping point was watching a sysadmin edit resolv.conf and type "namesrever": vim picked it out in reverse red. This mistake could otherwise have gone unnoticed for a while. Good crutch.
I recently re-watched Yaron Minsky's "Effective ML" talk where (towards the end) he talks about making read-only and read-write types. That's where I thought Jamis was going with the state machine example: one could tell an object "yo, make yourself immutable!" (ie redefine your methods so that you can't change yourself). But in an OO world that seems more neatly achieved with subclassing. [To the extent of faking anything "immutable" in ruby"].
There's #freeze I suppose... and no #unfreeze. Which is perhaps sensible :) And #freeze only guards against new assignment to instance variables; it doesn't guard against an instance method mutating the content of an instance variable (def esquirify! ; @name << ' Esq.' ; end). So there's that. But I'm far from convinced...
Python has this "inner-methods" capability (with saner scoping) which is a great antidote for python's limited lambdas. But that's not a problem with ruby.
It's a neat trick (and nice to read something from Jamis again). Are there any sensible use cases?
Edit: heh, that's funny, you edited your comment as I was replying? Now we just need someone to build it for us :)
https://github.com/raymontag/rust-keepass/blob/2b7b701b69541...
unsafe { ptr::write_bytes(self.encrypted_string.as_ptr() as *mut c_void, 0u8, self.encrypted_string.len()) };
?Is there a nice, light, better-than-betterthangrep[1] static analysis tool that would help with this sort of question? (I suspect the decay to pointer would, for example, elide this detail from llvm's IR?).
"2.6 B1 and B2 are two 128-bit blocks encrypted with Twofish [TWOFISH] using P' as the key, in ECB mode. These blocks contain the 256 bit random key K that is used to encrypt the actual records. (This has the property that there is no known or guessable information on the plaintext encrypted with the passphrase-derived key that allows an attacker to mount an attack that bypasses the key stretching algorithm.)"
(clearly there are far fewer of those around but they do exist)
A small correction -- from the symantec blog post:
"this file has been in the wild since late 2013 and it was first seen in Virus Total around the same time. However, we have only seen this sample broadly distributed recently. Distribution in 2013 was minimal, and we saw a gap of a year and a half before it reappeared again."
The release at http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... says that it affects both gethostbyname() and gethostbyaddr().