zwp

23 ms·

181.
by zwp 15y ago
Neat idea. What do you suggest for non-US volunteers (and callers, although I suspect that is harder to solve, at least for free)?
182.
by zwp 15y ago
Yes, I prefer this, definitely more lispy. I blame seeing too much of clojure's "defn fart [ args ]" syntax ;-)
183.
by zwp 15y ago
From the Examples: fart => [ :fart, [] ] fart 1 => [ :fart, 1 ] fart 1, 2 => [ :fart, [ 1, 2 ] ] Why isn't the single argument call: fart 1 => [ :fart, [ 1 ] ] ? ps. this is also fun: http://parset
184.
by zwp 16y ago
> Nobody attacks data centers. No really they don't. I suggest that these "facts" are too general: nobody currently physically attacks this sort of datacenter in the US. There are clearly many examples of physical attacks on other sorts
185.
by zwp 16y ago
Whilst the system software is vulnerable this doesn't gain a lot (you're in Thomas' arms race): malware intercepts the transaction request and requests "please scan your fingerprint to sign transaction of $1"... then quietly presents a $100
186.
by zwp 16y ago
> The only thing you can do [...] Or you could build a trusted end point. Otherwise even two factor auth is only palliative. (But yes: cost-benefit, I hear you). http://www.businesscomputingworld.co.uk/two-factor-authentic...
187.
by zwp 16y ago
> the key is in being curious and exploring That reminds me of another hacker: "I think one of the most important guiding principles has been this: — that every moment of my waking hours has always been occupied by some train of inquiry
188.
by zwp 16y ago
Even when a bug has been fixed in trunk a vendor may not wish to reveal the details of an exploit (either publicly or "just to zed"). A sensitive researcher may not wish their details of their techniques or findings to be revealed to a wide
189.
by zwp 16y ago
The process isn't clear to me. So the vendor communicates "fixed" to you? Or do I report to the vendor and to you simultaneously using this mechanism, and then I subsequently follow up with you? Does the vendor communicate with me? You? Bot
190.
by zwp 16y ago
Faux vulnerability reports might be slightly harder to spot than your average Nigerian Princess. Will you validate my exploit for IBM RACF on OS/390?
191.
by zwp 16y ago
Zed will act as a clearing house? There's no danger scale (CVSS or whatever) for customers and no comp for, ahh, researchers. I don't understand how this will work. Also clearly demonstrated that it's easy to submit reports. So... 1. Spam v
192.
by zwp 16y ago
Great I think that got most of it (validation!) but revocation checking worries me and a skim of the OpenSSL (0.9.8o) sources doesn't leave me with the warm'n'fuzzies. s_client.c calls SSL_CTX_set_verify() (the default verifier). Results fr
193.
by zwp 16y ago
Wouldn't it be great if some (smart, enterprising, generous) person could produce a browser extension to leverage these approaches for those that might find typing "openssl s_client -connect..." into a UNIX prompt a little bit much? Another
194.
by zwp 16y ago
Any non-privileged user can "dump the proc table" with ps(1). It's somewhat harder to break process address space separation (root privs, physical access, ...). It's not "fear" but rather "defence in depth" or perhaps "security evangelism".
195.
by zwp 16y ago
Also the fantastic Microsoft Pex: http://research.microsoft.com/en-us/projects/pex/
196.
by zwp 16y ago
The command, including password, is also visible in the process table. Some unices limit visibility of other users' processes but many do not.
197.
by zwp 16y ago
Thanks, yes misunderstanding: agree should be a framework protection not something developer should be sprinkling over code.
198.
by zwp 16y ago
> you can solve it by blindly calling #to_i on your inputs "You can solve it by blindly calling #h on your outputs" Ouch. We know that scheme doesn't work too well: it's why we had #h and we now have #html_safe...
199.
by zwp 16y ago
> if you could trick the server (64-bit FreeBSD) into connecting to sockets Proxies, SMTP gateways, FTP servers (active mode), ...