midas007

As a creator and a consumer, I think one has to not resent giving away something. Don't expect compensation, but ask for it if it's necessary to accomplish something as a stretch goal up from free. Also, there is value derived from street cred and it's better than a résumé.

https://github.com/steakknife

Do the correctness of generalizations matter to someone living on the street?

It's hard to get off the streets and back to "normalcy" (or dignity) if people pretend you don't exist.

West is becoming more like semi-urban India as the vice-versa... flattening.

Renamed to https://github.com/steakknife/devops_toolchain to avoid confusion.

A collection of individual tools that can be cherry-picked to solve nitty-gritty problems.

Ugh. What's most needed is a erlang-platform like haskell-platform.... bring together vital tools (proper/dialyer/etc), have a great package index (like hackage/pypi/rubygems) + package manager and have a skeleton project generator (rails-ish) that sets up what was asked for.

Convention > configuration

The easier it is to get going and contribute, the more people will use it. (Haskell pushed hard on this later on and has really benefited. Node did it early.)

That's what I was after... confirmation that it's a Tragedy of the Commons.

There's political ammo now to make necessary changes in how things are done to make sure OpenSSL, TLS WG doesn't continue with business-as-usual.

Amazon is missing the entire last-mile delivery pipeline apart from some shared boxes and jokes about quadcopter delivery.

Also, Google Express is way ahead given the number of trucks and cars going about from Costco and other local merchants, which is coming at Amazon from the other side.

Building it would effectively be starting from scratch and competing with FedEx, UPS, DHL and everyone else. And if it doesn't work, they'll be stuck with capital tied up in it.

Further, it's going to take a long time and a LOT of capital, and it still might not work AND still not be any better/cheaper, whereas FedEx is a known quantity that works. FedEx has a lot more experience than just delivery: it does lot of logistics and emergency logistics outsourcing for a lot of companies... and it would still be viable revenue if Amazon controlled them.

Yeap thanks, have used both.

It's just optional, and therefore doesn't get used much on open source projects. So the average quality of code suffers.

Whereas something like Go where extra import are hard errors, making best-practices mandatory keeps code to certain standard and it's zero work to setup.

The Oracle JVM is pretty versatile and has been beaten on in production on an extremely large scale, as much as M$ CLR.

Java as a language though was a primary response to over-correct and over-optimize for secure, correct, safe code based on the history of C's shortcomings. There's are many other lessons that have been learned since.

Java is really hard to beat apart from specialized formal methods verifiers (coq, CVC4), strongly-typed functional languages Haskell and similar derivatives for embedded industrial systems. If you're involved in safety critical systems, you should be using the simplest and easiest to understand formal methods tools as possible. If something's too esoteric, fewer people will be able to double-check the work.

For wider participation, it's a tradeoff to use one of the more popular languages that lack correctness aspects because of the absence of a learning curve.

Yes, it's best to use the smallest tool (orthogonal language and libraries) for the job because it's less to test and maintain, and more likely to be correct.

Elixir is neat, but it takes dynamic languages much farther away from static type checking.

Static compilation and compilation speed make Go very attractive for large projects.

It's essentially duck-typing iOS Objective-C protocols, but closer to how RubyMotion basically makes them optional.

Seems like a bump in the road, but it's something Bezos has to stay on top of to not be too long term to lose investor interest.

FedEx/UPS + Amazon merger would still be a good move and lock up last-mile distribution that only WalMart would be able to touch, but then WM would have to pay a premium for whichever chair would be left.

I worked at a dept with ~2.5% acceptance rate.

There were two, subtle factors in play: soft ageism and PI's hiring their clones (in thought, gender and race).

So the dept gravitated to predominantly two minorities, at least in terms of staff, faculty, visiting researchers and grad students.

But that's not an acceptable assessment of leadership for a vital crypto WG, much less the leading implementation. So far, OpenSSL has added one dev and it seems like business as usual. Does anyone know if anything's changed at TLS WG (I'm not on the mailing lists)?

In other news, I ported LibreSSL to OSX today[0].

[0] https://github.com/steakknife/libressl

The problem as per the Phusion blog article is that the runit and possibly daemontools equivalent commands don't set all env vars: HOME, USER, GID & UID, it only calls setgid() & setuid() IIRC. (envuidgid only sets UID and GID[0]) This causes breakage for lots of apps that end up inheriting root's env instead. :(

Here's the go version I wrote, so there's no need for dep on Python/Ruby/etc on the target system:

    setuser USERNAME COMMAND [args...]

    # how to build it
    go get   github.com/steakknife/my_init/setuser
    go build github.com/steakknife/my_init/setuser
    # creates setuser exe here

[0] FR issue submitted as https://github.com/bruceg/daemontools-encore/issues/18

Maintainers either will or won't accept that forks are the sincerest form of flattery.

No problem, just wrote a tool for that:

    waitport [-u] port [timeout (float)] # -u = UDP instead of TCP


    go get   github.com/steakknife/my_init/waitport
    go build github.com/steakknife/my_init/waitport
    # creates waitport bin here

Ahhh. Yup, I just lightly-forked LibreSSL to bring back some build infrastructure to non-OpenBSD platforms. It's easy for folks to get get carried away, and there will probably be some quiet backpedaling.

https://github.com/steakknife/libressl

But then they would think twice before furthering "...serves too many interests, and (particularly in the TLS portion of the tree) is a grab bag of functionality" [0] of un-security-like features like heartbeats. They might think: "Do I really want to write tests and a demo for this, or can I make do with something simpler?"

If not, then this suggests a lack of clear guiding principles of what is in-scope and what is not &| insufficient questioning of adding new features.

[0] https://news.ycombinator.com/item?id=7566456

Interesting, last time I did this was 1996 (and last time I wore the net admin hat) we had our own range for internal use.

Just gotta make sure OSPF, (E/I)BGP and L2/L3 drop these ranges though.

What's the best green-field recommendation for said companies?

One thing that would limit feature creep would have the TLS WG maintain a POSIX reference library implementation, standard library compatibility interface (header file) and a comprehensive test suite. Because once the maintenance of that hits the people making suggestions and decisions, priorities will adjusted. (It still takes work to do the right thing regardless, but at least there would be a baseline, and behavior across implementations would be more comparable.)

Also, accelerate the sunset of older specs so that deployed code will have to stay more current to even function, rather than interop'ing with old code that will never be patched.

Thanks. I'm the 😈, really. }:) <-- just in case you're using an ascii browser.

https://github.com/steakknife/ruby-net-ldap

Shameless self-promotion: Clients call for this devil if something's hard or something's broken.

There is none, OpenBSD uses CVS.

Yup. I've done enterprise Rails consulting, which is almost a contradiction in terms. But it's possible and I've brought fixes like net ldap to work with AD.

Edit: Can't take all the credit, client hacked together the first version but we managed to extract it for "the greater good." Also fun stuff like XML-RPC (Xen API -> gem xenapi, VMware (gem rbvmomi)), which wasn't bad and worked OOTB. Wished MS exposed their APIs as RESTful endpoints, because WinRM + gem winrm just doesn't cut it with some products... generated powershell run by an agent instead. For some products, even having the (.someextiforgot) files that describe the API, there's no MS docs on them, so lots of trial-and-error in PowerGUI to find the right objects and methods (Yuck).

Generally: don't trust anything from the outside world or anything that can transit untrusted infrastructure, that means check types and sanitize values before passing along. Break loudly and quickly to get attention for a fix. Keep the codebase as tiny as possible too.

Ruby: recompile with minimized OpenSSL 1.0.1+ (LibreSSL when possible) and with patches that improve Ruby's default OpenSSL security.

https://gist.github.com/steakknife/8228264

https://gist.github.com/steakknife/10092587

https://gist.github.com/steakknife/10096008

For Rails apps: use brakeman as one part of security audit strategy

For gem authors, sign them (please!): I wrote waxseal to make it dead simple

    [sudo] gem cert --add <(curl -L https://gist.github.com/steakknife/5333881/raw/gem-public_cert.pem) # adds my cert (do once)
    [sudo] gem install waxseal --trust-policy HighSecurity

For gem users, find which aren't signed

    Add this to ~/.gemrc gem line:

    --trust-policy MediumSecurity

    or just if there's no gem: .... already: 

    gem: --trust-policy MediumSecurity

For anyone using git, sign your tags (git tag -s ...) and commits (git commit -S ...) por favor

Yup, it's one of those annoying things that makes run scripts more complicated. I rewrote phusion's runit setuser helper in Go because it didn't set all the right env vars.

https://raw.githubusercontent.com/steakknife/my_init/master/...

It's cool. I think it's a good idea for them to get more than $4k AND code help from industry.

Exactly. When a popular security project has no clear competition, a code "monopoly" may exist and it's much easier to get complacent. By introducing "competition," it tends to keep both projects adversarial and vigilant... which is exactly what a security project needs.