Dryly amusing: my .sig for years (a decade or so ago) used to contain a short example of just how zsh does handle NULs in strings.

Loosely speaking though, the moment that you’re using the beyond-POSIX features of bash or zsh for anything other than REPL control, that’s a sign that you’re entering technical debt territory and should be rewriting, now that the shell prototype has confirmed what needs to happen and what the general failure modes are.

I can’t decide if Let’s Encrypt is a godsend or a threat.

On one hand, it let you support HTTPS for free.
On the other, they collect an enourmous power worldwide.

So those who lost their .mcdonalds email addresses are now Old McDonalds?

An IMAP server handles N users and can have M shared folders readable by all of them. Rather than have every user be presented with the complete list, each user has a maintained subscription list and mail-clients (used to? mine still does) default to only showing the subscribed folders, with a toggle to switch to see all folders and sub/unsub as desired.

I for one actively use this, with mail folders. Some lists which I might occasionally want to delve into local copies of, I unsub from. The mail still flows in, I don’t need to get notified for it, but I can search it locally when I want.

You haven’t even touched on the two vaguely-compatible revisions of the ACL flags and their meanings and how the permissions need to map from one to the other. ;) Nor that for the sake of letting some ancient servers continue to be inefficient, clients are barred by spec from certain behaviors across mailboxes. The IMAP police will tell you how wrong and evil you are for wanting, say, a count of total/new/unread mail across 30 mailboxes. Sometimes you just have to ignore the spec and say “this tool is for competently written IMAP servers” and go ahead and issue a bunch of STATUS commands.

Disambiguating async notifications from part of the response to a given command almost requires an organically grown codebase handling the entire history of IMAP, rather than having a clean model.

There’s a reason that the IETF Working Group to turn IMAP+SMTP into something which mobile clients could use for sane handling of attachments ended up being called “lemonade”. When life hands you …

[full disclosure: I’m the Phil referenced; I’m not an SKS maintainer, but did write various wiki pages and do have patches in the codebase]

The attacks causing disks to fill are problems with specific keys breaking reconciliation and triggering transaction failures in BDB, leading to many GB of disk usage by those unable to get the broken key.

On-disk size has gone from around 6GB to 40+GB in the space of a couple of weeks, and that’s what’s knocked a bunch of SKS systems offline, repeatedly. All the decades of cruft is an order of magnitude less disk space than that caused by a couple of keys designed to break SKS.

Also, Kristian is one of the SKS developers, but is not the original developer. He, like everyone else involved, is a volunteer with a day-job unrelated to SKS.

I’ve been on the SKS devel mailing-list for probably 8 years (guess) and I’ve never seen hostility to the idea that SKS should change or to any reasonable proposal for doing so. I’ve seen various levels of resignation and annoyance at (1) people who propose changes without thinking through how to deal with the fundamental SKS reconciliation algorithm; (2) people who make demands that others do work for them, but never contribute patches themselves. The Almighty Designers who sketch out a non-viable proposal and can’t understand why others aren’t prepared to leap to do the work to make their vision a reality.

In stark contrast, in March Andrew Gallagher posted (thread “SKS apocalypse mitigation”) and took on board the points about algorithm and design issues and himself put in the effort to design something which might work. Haven’t seen code yet, but he’s demonstrated how easy it is to get a productive discussion if you’re willing to take account of engineering design constraints; so many before have instead pouted and stomped their feet and said “well that should be fixed”.

Hockeypuck has been around for a few years; it’s gained a little traction, but is not a silver bullet: it peers by using the SKS reconciliation algorithm and what’s needed is a design approach to change how reconciliation happens, not just a different codebase. SKS itself is GPLv2, Hockeypuck is AGPLv3, both are available for folks to work on and propose changes.

Yeah, I know someone who runs a keyserver and they are getting absolutely sick of responding to the GDPR troll emails.

Love the idea to use activitypub (the same technology involved in mastadon) for keyservers. That’s really smart!

The less successful person didn’t write much code, and he had excellent reasons why: I’m too busy! The person who made the request can’t wait! I have 100 other things to do today! Nobody’s allocating time for me to write code!

Google has this fixed. SREs can only spend a maximum of 50% of time doing manual admin work.

Slide 42 figure 6’s Representation of a break statement (Greenfoot, 2006) is really intriguing as an example of use of color and graphics to make it much easier to spot potential problems cleanly. Has anyone seen a plugin for Vim which can do something like this, either for C or for any langserver backend? While C macros might make it awkward, there’s some codebases (and a few security-critical bugs) which would benefit from being able to have this sort of view while looking at them.

1. Deploy DNSSEC signing for your zones. It won’t protect everyone, but it rewards the behavior you want to reward: systems behind verifying resolvers will be protected from these shenanigans. If PKIX issuers aren’t using validating resolvers before issuing DNS-proven certs, then that’s a security failure on their part.
2. If you’re in a position to do so, ask your network provider where they are on using ROA verification for routes, as part of RPKI security. My colo box is hosted with people who’ve been filtering on this basis for a few years now. This is no longer new functionality and we’re reaching the point where we’re in danger of the lawyers getting involved to argue gross negligence if operators aren’t filtering out provably bad route advertisements.

Urgh, what a horrible page. @johnblood this page is a clusterfuck, hope your ad revenue is nice.

I’m not convinced, the cost of the extension boards is insanely high given what the cost would be to just shove it all on one board and that two of them don’t have active components - you need to purchase the actual e.g. WNIC or SFP module on top, not to mention antennas for wifi

With the super professionally produced video makes it seem even more like crowdfunding fodder to make a buck.

So, Perl’s Parrot VM system was just ahead of its time?

Given how much confusion is created by systems which do allow “foo.bar” and “foobar” to be different email addresses in the same domain, for different users, Gmail saying “we won’t allow that” is wonderful. Given how often people don’t correctly write down dots or whatever when copying email addresses, Gmail’s behavior is also good for getting the mail to just flow.

Saying Netflix shouldn’t have to have insider knowledge misses that (1) they made assumptions which required that insider knowledge, and (2) most sites make insider assumptions. Continuing with 2 for now: every site is allowed to have whatever rules they want for the left-hand-side (LHS), and per the standards the left-hand-side is case-sensitive. If I want “bar@” and “bAr@” to be different email addresses, that’s my business. Any email handling system which generally loses case of the LHS is, technically, broken. The federation used by email allows whatever systems are responsible for a given domain to have complete control over the semantics of the LHS.

In practice, the most widely deployed LHS canonicalization is almost certainly “be case-insensitive”, followed by “have sub-addresses with + or perhaps -”. IMO, the Gmail dot handling is incredibly sane and everyone running mail-systems should seriously consider it.

If I went out filing bugs against systems which made the case-insensitive assumption, then I’d be dismissed as a crazy person. In practice we (almost) all accept that some assumptions will be made. If you want to be safe, or not have to make assumptions, then validate the email addresses used at signup.

A friend had some issues with his wife because four different people had signed up for Ashley Madison using his email address (first-name @ gmail.com) and A-M never validated. Perhaps the potential consequences here highlight why not validating email addresses at sign-up or email address change should be interpreted (legally) as reckless negligence. If you’re going to decide that you don’t need to validate, then you assume responsibility for knowing about the canonicalization performed by every recipient domain. So the author of this piece is flat wrong: the moment Netflix decided to not bother validating email addresses, while also using email addresses as authentication identifiers, they assumed complete responsibility for the security consequences of having correct information about canonicalization used in every domain, to keep their authentication identifiers distinct.

(disclosure: as well as the hat, I’m also a former Gmail SRE, but had nothing to do with this feature)

Too fast and responsive to be legitimately phpBB.

I can’t help but wonder at having does-added methods which override the self-same method and using this to implement a state machine.

There are various command-line concoctions such as password-store which stores PGP-encrypted files in a Git repo, but that doesn’t improve my situation over 1Password. I would still have to manually look up passwords and copy them to the clipboard. These command-line packages also lack mobile apps and syncing.

That’s not completely true. I use pass with syncing via a private Git repository, there’s a Firefox plugin with autofill support, good mobile clients for both Android and iOS. The best password management system I’ve used (I’ve been a user of 1Password for about 3 years before that). Being able to do git log to see password history for a website is awesome. Bonus point: OTP plugin works like a charm.

The key to this work is throwing out old assumptions and requiring explicit guest support.

Historically, VM systems “had” to be able to boot guests which didn’t need to know they were in a VM, but the guest could optionally implement dedicated “hardware” drivers to have more optimized I/O than through emulated devices. Still, you could take the install media for various OSes and install them all.

This project requires explicit guest support for basic boot-up. Which is great, if your model is around managing everything in the guest and you can make that demand. They reap major benefits from doing so, and there’s no reason for everyone creating images for deployment needs to be held back because the target system is also trying to be compatible with stuff which you’ll never deploy. But it’s very much a case of needing the guest to be compiled explicitly for the target hosting platform.

Since the competition is structured containerization with something like a Dockerfile defining entry-points, environmental dependencies, etc, this is not different. It’s a great trade-off. But it is made possible by the target audience having moved and adapted to a world of on-demand machine instances and container workloads.

Link now 404s; going from http://vjolt.org/archives/older-volumes/ to volume 2 issue 1, we see:

2. The Use of Encrypted Coded, and Secret Communications is an Ancient Liberty Protected by the United States Constitution [html] [Adobe .pdf format]
   By John A. Fraser III

• http://vjolt.org/wp-content/uploads/2017/Articles/vol2/issue/vol2_art2.html
• http://vjolt.org/wp-content/uploads/2017/Articles/vol2/issue/vol2_art2.pdf

“I ask you to judge me by the enemies I have made.” — Franklin D Roosevelt

Neat troll at the end:

id also like to thank andrew loyd weber, inventer of the world wide web for making the internet

[sic]

Author is generous. Originally from UK, moving from NL to US in 2006 I ended up remarking to colleagues that the US banking system was like moving back to the 1970s. 11 years later I’m still using passwords for bank website authentication, with knowledge of a bank account number being a closely held secret.

IBAN fee-free international transfers to friends or for paying bills (same day in-country, instant if same bank chain); fee-free cross-bank ATM withdrawals; sane security for web sign-in or initiating transfers; banking websites which don’t require you to lower the browser security settings to work; PIN-less on-card small-balance cash so you’re not typing your PIN into everything (paying for parking or using vending machines), all stuff I am still waiting for. Well, aside from the browser security settings: American banks have mostly caught up there.