HorstG

There should simply be a heavy tax on all presence-required jobs, payable by the company. Suddenly, as soon as there is monetary incentive, things will work quite fine remotely, "concerns" be damned

Certificate auth for http with TLS and Kerberos auth for http is specified, supported by all (major desktop) browsers.

However: The UX on the browser side is shitty as hell. Certificates display weird nagscreens, without being able to specify proper defaults like "use this cert for that site and don't bother me again". Certificate enrollment has been broken (not that the form element was ever great) by all major browsers, to be replaced by "do something in Javascript maybe, if we get around to implementing a new API some time". Oh, and no logout...

Kerberos needs a parameter at browser start or an about:config setting, is incompatible with using multiple TGTs let alone automatically selecting the right one or gasp getting a new TGT for the user from the proper KDC. The only thing that kinda works mostly is using the standard company login TGT. Oh, and logging out doesn't work...

Oh, and of course most mobile systems are broken or just unsupported.

The sorry state of browser auth is 100% on browser vendors dragging their feet on those problems that have been known for around 20 years or so. And no, webauth won't save us, it'll just be another shitshow most likely.

It isn't that nobody thought of busses or trams. Its just that they are always too sparse, slow, limited in times, capacity, safety and comfort. I believe the break-even is of being able to replace cars is somewhere around a 5min schedule over the day and stations in at most 200m walking distance from everywhere.

Oh, and of course being comparable in speed to at least a bike.

That leaves only subways...

Drug dealers in Berlin populate the parks and subway stations mostly. Easier to hide in the crowds or shrubbery, if they hide at all. Police usually never bother them.

This only works in bigger cities, where there is plenty of heavily subsidized public transport such as Berlin. Most smaller towns that went car free killed their businesses or made them move to shopping districts on the outskirts which are still reachable by car. Leading to "dead" inner parts of town and very unhappy citizens. Oh, and skyrocketing rents in the subsidized cities such as Berlin...

"Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.

Agreed. Most vendors supply an unholy mess of weird setup.exe, shellscript installers, omnibus packets or appliances as well, containers are not alone here.

Edit: To clarify, containers and VMs are somewhat special in that it is very easy to do the wrong thing, and that you get a lot of rope to hang yourself with. The application developer by. default takes responsibility for the whole OS stack (maybe except the kernel with containers) but usually doesn't handle it very well. Whereas with packages or even setup.exe, the default case in most IDEs and tools is to package very little, and only upon request (using omnibus e.g.) to include the whole shebang

edit2: the definition of 'vendor' of course includes a lot of OSS projects who are just as bad as most commercial vendors in this regard, as exemplified by all the aforementioned Apache Foundation Java Crapware

Agreed, up to a point:

Ever tried to security-update a vendor-provided container which you should never touch because of the vendor's support and warranty conditions? And even if allowed to touch it, the mess that it usually is: app running as root in the container, stuff chmodded a+rwx -R, weird base distro, build script is just a wget, cp -R or "this binary magically appears from somewhere". With a helping of " only works if the directory structure and environment look like the devs machine".

Containers are the ultimate expression of "it compiles, let's ship it" laziness

Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed.

Of course this is work for application as well as library developers, designing and keeping compatibility is hard. Most would rather build the new shiny, consequences be damned.

In Germany there is the Schoeffengericht aka jury trial for intermediate crime. Schoeffen are also called Laienrichter, layman judges, there just aren't that many of them and procedures are different.

The decision of facts (as opposed to legal decisions) is a majority vote of professional and layman judges...

edit: major —> intermediate

The EU will never close tax loopholes since there will always be a veto from the likes of Ireland, Netherlands, Luxembourgh or UK.

HP actually has a working firmware update mechanism for all their gear. Its a bootable Linux liveDVD that starts into a browser talking to a local Tomcat instance which applies necessary patches. For many cases its also possible to invoke patching from your normal Linux installation. However, a reboot is mostly still necessary, e.g. for disk firmware which the controller applies after its own new firmware has been loaded (sometimes takes more than one reboot).

The system is quite a lot older than fwupd and less flakey usually. Google for hpsum or HP SPP

Yes, its possible. However, prices go up with age.

The HP specific part is just to make sure that the HP disk vendor lockin works: HP controllers only talk to HP branded disks...

Different SSD vendors is impossible with HP servers and controllers, they only talk to their own expensive gear. So the disk diversity option is off the table for HP customers.

Readability and familiarity are not the same but closely related. There is nothing inherently more or less readable in the rust or haskell tree example.

I think there is work on "readability", just in another context: Its called typography and orthography. And I think the gist of it is: Do it like everybody else does, first and foremost, strange and unfamiliar equals unreadable.

Calling it Box is confusing. unique_ptr would be an improvement for the name, or maybe HeapRef. The problem is exactly that rust chose a misleading name Box (boxed types are something entirely different in most languages) instead of the obvious C(++)/Java-like _ptr, ref, * or & notation/convention

There is a huge unreadability right there staring at me: What does that Box<> do, and why? Rust is borrowing more and more of the obscurities of C++, and thats not a good thing...

The article gives very dangerous advice, especially for networking code. Padding will not be overwritten and when transmitting the struct (provided there is no attribute packed or the compiler ignores it) information will leak.

Yes, someone will point out that there are languages that do not have such problems. However, when still using C, one has to be extremely careful...

The vendor tried to hide the vulnerability from the public, its customers and its future business partners and to delay disclosure until after a favourable business deal. What the hackers did wrong here is failing to recognize that immediate full and public disclosure is the only ethical course of action in such a situation.

I do consider HashKnownHosts harmful. Not only does it provide only the shallow appearance of security, as TFA shows. Also, as other commenters have argued, an attacker can often obtain the same info from syslog or shell history.

But most problematic, I think, is that HashKnownHosts makes properly maintaining the known_hosts file tedious and error-prone. Its harder to remove hosts with known changed keys, and almost impossible to remove unneeded obsolete entries that have accumulated. Yet those old and obsolete keys could have been obtained by an attacker from recycled hardware or just by owning an old never-updated box. While this scenario might be unlikely, I would consider it just as unlikely that an attacker would find information only in known_hosts.