I'm developing a twitch whenever I see the word "modern" in a software description. It doesn't actually say anything about what you're doing.
First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahead of time, and not adhoc added New-Jersey style. Changes to the API need a rename, not just a major version bump. Hand-waving simplified development models are okay for a post-modern everything is allowed world, whilst modernism aims for long-term goals, making it easier for the user, not the developer.
Modernism is based on "Form Follows Function", and not the other way round. Reduce it, abstract it. Functionalism is everything, marketing is less important.
And to avoid popular misconceptions, in our current era "Modern" doesn't mean "New" at all. Modern is more old Stanford-style development. Check the Unix Haters handbook e.g. Rust is new, but this choice alone doesn't allow the use of Modern. Rust is better, because of its superior semantics and guarantees, whilst still adhering to the C ABI. It's a library for everybody afterall, and not comparable to the latest ocaml, haskell or lisp TLS library, which only adheres to their ABI and needs wrappers to be useful for projects in other languages.
So while I appreciate your attempt to redefine "modern" with all the above I'd rather people just used the more verbose explanation instead of using the meaningless term.
Grandparent referred to the meaning of the jargon term in architecture. It's not his personal redefinition; it's an interpretation of a widespread understanding of the word mapped analogously to software.
Jargon is important. We'd have a hard time communicating if we could never create new words or imbue existing ones with new meanings by analogy. The more verbose explanation is mostly useful for laymen and beginners.
The word has spread in popular vernacular to mean 'the present' or 'contemporary' but for historians, philosophers, architects, art critics, critical theorists, etc. "modern" refers to a bunch of things, and the "modern era" is considered by many of them to be either over, extended, or exaggerated.
A modern SW project consists typically of 1-2, max. 3 devs, a typical post-modern project of 20-200. With such member sizes consensus is rarely practical, political correctness and CoC discussions are taking over development, ABI and API's are driven by design and not by functionality and longevity.
I.e. modern development is small, functional and not designed by committee.
Is this something you feel to be true, or do you have any evidence to back up that claim?
New Jersey style? The PERL style? I've never heard of "New Jersey style." Are you joking? I'm almost positive that Perl didn't influence openssl development at all.
"Modern is more old Stanford-style development." I think you've read way to much into this. And sorry citing the "The UNIX Hater's Handbook" doesn't do much for the credibility of your odd argument.
So, who won? Nobody. Both had success. Most successful, though, was combining a little bit of MIT method, cathedral, and ship fast from "worse is better." That's IBM and Microsoft's approach. A hybrid worthy of another Gabriel essay.
http://windowsitpro.com/windows-client/windows-nt-and-vms-re...
Bill robbing Apple of GUI is well-known. Less known is he stole a more robust and secure architecture from OpenVMS that was most rock-solid of OS's. They managed to show what would happen if OpenVMS had no QA process during development. Yet, recent efforts have gotten Windows Server reliable enough that the connection is more believable. :)
2. New and common; trite; commonplace. [Obs.]
[1913 Webster]
We have our philosophical persons, to make modern
and familiar, things supernatural and causeless.
--Shak.
- C++: uses C++11 features, avoids non-RAII resources, prefers standard libraries over older, platform-specific libraries, not written as "C with classes."
- C: doesn't do weird stuff like bypassing malloc(), avoids undefined behavior.
- in general: has a test suite, probably uses continuous testing like Travis, uses modern language features to achieve cleaner & more robust code.
Can you elaborate?
Use any of the debugging libraries that shim in their own alloc routines, you bypass malloc (or at least do a bunch of things that impact what gets malloc'd).
> Speed is important for a malloc implementation because if malloc is not fast enough, application writers are inclined to write their own custom free lists on top of malloc. This can lead to extra complexity, and more memory usage unless the application writer is very careful to appropriately size the free lists and scavenge idle objects out of the free list.
An example of such an optimization is the arena allocator[1][2] employed by protobuf. Custom memory management schemes are not uncommon in performance critical code.
0: http://goog-perftools.sourceforge.net/doc/tcmalloc.html
1: https://en.m.wikipedia.org/wiki/Region-based_memory_manageme...
2: https://developers.google.com/protocol-buffers/docs/referenc...
I work on the protobuf team at Google, so I'm aware of this.
Two things about that:
1. The underlying blocks for the arena allocator still come from the system allocator.
2. Because the arena allocator inhibits the capabilities of standard malloc-debugging tools like ASAN and Valgrind, the protobuf arena allocator includes special ASAN-aware code to mitigate this:
https://github.com/google/protobuf/blob/d64a2d9941c36a7bc2a7...
However, that code is ASAN-specific. It won't help other tools like Valgrind. So yes, different allocators are sometimes warranted for specific patterns like arenas. But if all you want is plain malloc()/free(), you should call malloc()/free().
If you're writing a library, letting the user specify their own allocation callback is also great, since it lets the user do whatever custom bookkeeping/pooling/etc. they want to do. But by default just call malloc()/free() (IMHO).
- in reference to Mozilla's "Modern TLS" profile: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...
- as an antonym for the unlimited backwards-compatibility, kitchen-sink-comprehensive approach of (say) OpenSSL or NSS.
It's a very handy tool when you have disparate networks.
My guess? They don't use it in their applications, so they don't think anyone else uses it, either.
TLS client authentication is widely used in 802.1X (WiFi and wired) authentication. I've seen it used in a lot of other situations, e.g. web client access (client cert + user password), LDAP client access, etc.
Maybe there are security issues in client authentication which they're aware of. If so, they should share them. But simply labeling client authentication as "obsolete" shows a close-minded attitude.
Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.
Am I missing something better?
(We already have the infrastructure in place to deal with client keys)
1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unlike the server identity usually identifies a user; see sibling comment which confirms this) is sent in the clear. That's a big privacy failure.
2. to work around (1), some implementations do an initial server-auth handshake, then immediately renegotiate up to mutual-auth (renegotiations are encrypted). Renegotiation has quite a dismal history, and I definitely want to avoid it.
3. as a follow on from (2), the standard never described what implementations are expected to do if client/server identities change during renegotiation. This (partially) resulted in https://mitls.org/pages/attacks/3SHAKE
All of these are fixed in TLS1.3: client identities are encrypted and renegotiation is dropped.
At least in the environments I use TLS, which is interservice datacenter communications, there are no privacy issues (especially since you can just look at what container a connection comes from for the same amount of identity leaking).
But I do need mutual authentication, and want to avoid rolling my own crypto for it--so does Rustls expect to support client auth in TLS 1.3 when that spec is finalized and implemented?