No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER.

The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated.

As for your former point: I don't follow. Go's deployment infrastructure is a superset of C's, and, if you're a masochist, almost everything in C's deployment toolkit is available to Go projects as well.

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly.

My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of view of a group which does one thing, but not from my point of view, running large numbers of diverse systems.

When libfoo gets updated, all N packages on the system which use it via dynamic linking gets the benefit as soon as the packages restart. This is highly desirable.

If Go-libfoo is updated, each of those N packages needs to be rebuilt, but I don't have a programmatic way of finding out.

If there are N teams developing those packages, some of them will be faster off the mark than others, and now I have a window of vulnerability that is larger than the one I had when I could update libfoo on day 1.

You have multiplied my workload. I won't do that without a really good reason.

If the Debian people don't want to include Go for some logistical or religious or religiously logistical reason, that's fine with me. I don't think people should run critical infrastructure from Debian releases --- when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance --- but hardly anyone seems to agree with me on that, either.

But I notice you didn't respond to my SNMP point, which is disappointing, because I was hoping that at least some fake Internet points might accrue to my otherwise fruitless efforts at implementing SNMP from scratch three separate fucking times. Can I at least be rewarded for that by winning a dumb message board argument!?

There's even a cool trick to implementing BER encoders I could have talked about!

Instead, it looks like the thread is going to be about dynamic versus static linkinnzzzzzzzzzzzzzzzzzz.

> when things go wrong, you want to be prepared to patch source on a moment's notice, rather than waiting for the upstream synchronization dance

This is IMHO the most backwards logic ever. Everything about dpkg and apt makes this process easy, from running an internal custom packages repository, through to "apt-get source" for any system package on a moment's notice, through to having everything just magically revert back to Debian-patched versions as part of the normal upgrade process assuming you versioned your custom packages carefully.

A well run Debian shop is a thing to be seen, unfortunately it's not cohesively documented in any one location on the Internet. If there's any problem encountered in the wild on the Internet, after 22 years, there is almost certainly a solid process built into Debian to handle it.

Compare that to home directories full of tarballs of binaries with dubious compiler settings and godknows what else, I have no idea why someone would advocate against it, assuming of course they've actually done sysadmin anywhere aside from the comfort of an armchair

It's super easy to install a patch using dkpg and apt. I didn't question that.

The problem is that you have to wait for the patch to be bundled. I've watched that take a long time, while services I knew to be vulnerable had to sit there and be vulnerable because the organization deploying the service didn't have any infrastructure to apply a custom patch.

Consider the degenerate case, where you have to wait for a Debian patch because you paid for the research that found the vulnerability. More than one of my clients wound up in that situation. But that's not the only way to learn about a simple, critical source patch that won't land in a Debian patch for days.

You bundle or create it yourself..

    $ apt-get source bash
    $ cd bash*/
    $ quilt new my_urgent_patch
    $ patch -p1 < ~/my-urgent-patch.diff
    $ quilt add file1 file2
    $ quilt refresh
    $ dpkg-buildpackage ...
    $ dupload ../*.changes
    # trigger apt-get upgrade on target machines

That's fine. I don't care what you do with your self-built binaries once you manage to build them yourself. But too many firms have no infrastructure in place to do that. They wait for upstreams to synchronize to fix security flaws that they could fix directly.

scp and "dpkg -i" are readily available, but it's really not that much work to setup a repository (aptly, reprepro, apt-ftparchive etc.)

I know I'd personally chose maintaining the system packages and where possible put extraneous language dependencies in packages too (fpm comes in handy as it can deal with a variety of packages, gem, npm etc). It makes life a lot simpler when it comes to administering a bunch of systems and trying to keep things consistent.

> when things go wrong, you want to be prepared to patch source on a moment's notice,

That's a misunderstanding. What Debian, and every other mature Linux distribution, gives you are the tools to not only rebuild a package on a moments notice (try to build any non trivial third party package sometime, and compare that to rebuilding the Debian package) but also keep track of those patches over time (where did it originate? bug id? upstreamed yet?) and keep a bird's eye view over deployment (which nodes? when?). You need to ask yourself those questions, because your auditor will.

Good for you to implement SNMP, and using the f word in writing, but maintaining infrastructure is something else. Your reason to not use Debian for critical infrastructure should be because of contractual liabilities and/or support reasons, its build tools and associated policies are solid. It's not the only way to roll, but it's a perfectly valid one.

What is the cool trick to implementing BER?

you encode it back-to-front

i don't even

care

anymore.

> you encode it back-to-front

sorry, but i still don't grok it. for example, if you take a person 'object' defined as :

Person {

     name string (or equivalent asn.1 type-name, with type-identifier == 1)

     age  int (or equivalent asn.1 type-name, with type-identifier == 2)

}

since b.e.r is basically a tlv (type-length-value) encoding, a person with name "james" with age '10' i.e.

james_person = Person(name = 'james', age = 10)

gets hex-encoded as :

"james" : 01 05 6a 61 6d 65 73

"10" : 02 01 0A

so the whole thing looks like this:

"01 05 6a 61 6d 65 73 02 0A".

ofcourse this would be prepended with appropriate type-number for 'Person' with corresponding length.

if we assume that 'Person' gets a type-identifier == 3, then 'james_person' instance would be encoded as:

"03 06 01 05 6a 61 6d 65 73 02 0A"

where '06' == total length (6 bytes) of this instance of person object.

may you please elucidate your trick with the above example ? thanks for your insights !

I would think implementing SNMP from scratch is the reward in itself, right? Are ulcers not a badge of honor for you like they are me?

And yes, I agree. I think we're to the point now where sysadmin-style "I'll wait for Debian to entmoot on this TLS vulnerability and eventually drop something" server maintenance is on its way out for those who operate cattle. Especially high-visibility cattle, as you imply. The industry is teasing the post-distro world into existence but doesn't yet know what it's dealing with on that point. I don't even consider CoreOS a distribution, for example; I think it's more of what Linux will look like in several years time for cattle herders, while Debian and friends will continue to go in pretty hard on pets.

Dynamic linking creates more problems than solutions in a cattle fleet as opposed to a pet fleet. People who philosophically argue for one or the other are expressing their preference for how to administer a server and do not realize that it is a preference, and not "correctness," per se. The package manager argument is the same way. Execute the code and get it done, or be "correct" and only apply updates through RPM. Cattle, pets. It's all cattle and pets, and the arguments that spawn between the cattle camp and the pet camp will never be resolved, this thread included. People need to realize this, that there is not one way to operate a server, and my way is not more correct than your way.

My way, for example, comes with the baggage of an expected organizational structure to enable its mission. That's not always easy, and I understand that. I can say, however, that the SRE/cattle way makes a hell of a lot of sense at scale.

He gave you a really good reason: knocking out most severe, low-level errors in high-usage, critical services. You'll put work in for the risky ones. Why not the low-risk alternatives...

Static linking is also a thing in C.

Apparently gcc seems to be the only C compiler lacking this capability, thanks to glibc.

Also, you can use dynamic linking in Go since version 1.5.

gcc has no problem with static linking. glibc can be statically linked (with gcc or clang) except the pluggable parts, which is NSS. How would you reconcile static linking and plugins?

By making use of plugin selection at compile time, like we used to do when dynamic linking wasn't available in mainstream OSes.

The whole idea of NSS is to be pluggable to let the local administrator chooses what they need.

Back in the day when UNIX only had static linking that type of plugability was achieved via configuration files and UNIX IPC.

Dynamic linking just makes it easy to program for the same scenario.

As a result of that good intention glibc must now be compiled into each and every program that wants to allow a customization complicating life for anybody who writes system software in anything but C/C++. I would rather preferred for NSS to never happen and instead Linux defined a set of services available over unix sockets for things like DNS resolution or user/group databases.

i don't know if it counts, but there's musl-gcc, right?

curious, is there no glibc solution? Its just the libnss* that requires dynamic linking?

Actually, Rust would support updates for your SSL, ASN.1 and other libraries; because native bindings are widely accepted and used with Rust.

You can always use gccgo, which supports dynamic linking of the go stdlib

> Go's deployment infrastructure is a superset of C's...

That is true; but updates to native libs that would propagate to C, Python &al. will generally not propagate to Go because, like Java, Go eschews native bindings.

So you install the go equivalents from your distro. If your distro doesn't have them, you vote for them to add them (or go through whatever process your distro has).

The repo maintainers are going to be on the hook to rebuild every dependency every time any package in the dependency chain changes. That sounds like a nightmare versus the current scenario where only one package gets revved when a library has a bug.

If you have an automated build system (like OBS -- the Open Build System used by openSUSE) where dependencies are rebuilt automatically and security fixes can be pushed to maintainence automatically.

Not every time a library changes, only every time one has a security bug.

So either the repo maintainers do it, or they stop being relevant (for this use case). Or someone else comes along to fill the gap.

Having the shared library that can be replaced by itself, instead of deploying N things, is nice. Not sure it's the end of the world, but it's nice.

On the flipside, though, this is probably a case where using something like Rust could be excellent: stronger language support for eliminating entire classes of bugs but also able to be compiled down to something that can be a shared library.

I'm not an ML expert, but reading about the things the Mirage project has done related to TLS, leveraging OCaml to provide compile-time guarantees, sounds very exciting. Rust feels like it could be that bridge. Start rewriting core libraries in it: cleaning up old code, removing dead code, avoiding bugs by virtue of the language/compiled, in one fell swoop.

> Let's say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library. > My distro ships all the packages noted above, but not their Go-equivalents, so my work load now includes monitoring security-announce lists for eight different products, where before I monitored the security-announce list for my distro.

But say your distro includes the Go versions, but not the C ones... You're basically complaining that your distro doesn't include everything.

Regarding packaging, I mostly agree. However, I would highly recommend looking into the Nix package manager and our packages (and packaging infrastructure). Updating one of our go packages is sufficient for all other go packages to be built with the new version. So that would mostly solve the problem you're talking about.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...

(Sorry for being light on details; typing from phone)

https://github.com/whyrusleeping/gx is pretty cool.

You could handle it the same way that python handles it. Don't rely on a distro, have each person package their own stuff.