Notices by varx/tech (varx@infosec.exchange)

@ryanc @Mara I'm glad to see that, but I really have a hard time seeing 24647 as inflammatory. Is there some history here where an *earlier* attempt was actually inflammatory, so anything similar was also marked as "political"?

@StompyRobot ...pretty sure they just needed someone to look at the logs.

@feld Nope, just stuck into the README next to the "This project is licensed under the GPL". (Editing the GPL would be a different kettle of fish, yeah...)

Software licensing question, semi-hypothetical:

I encountered a repo available under the GPL, *but* there's also a note about "you can't sell this". This... isn't actually compatible with the GPL, and reveals the author's poor understanding of the license they chose. It doesn't matter for me, because I'm not planning on selling it, but it does raise an interesting question: What is the most likely *effect* of this statement?

- License grant is invalid?
- GPL prevails entirely?
- No-sale applies to original work, but not to derivatives?

I'm leaning towards the first one, myself. Curious to hear what others think.

@cuchaz Cavern has a problem that's very similar; my solution is for the friends to have to brute-force the list until they find something they can decrypt, but not have to do this *often*.

Not sure if this is appropriate in your use-case, but consider whether there's a way to "stabilize" the numbers you're sending your friends; if they can act optimistically on the presumption of the number not having changed since last time (if that's even a meaningful concept) then they get to skip the expensive step whenever they're right.

Barring that, it feels like this might require some fancy math involving combining multiple people's public keys. :-/

@cuchaz It's also pretty fast. The marginal cost on my 10+ year old laptop of performing an encryption or decryption is less than 80 µs. "Brute forcing" a list of 1000 small items until I find the one that's for me would take under 100 ms, which seems fine.

40k items would take about 3 seconds to process. At that scale I'd want to start using k-anonymity for sure; including just an 8-bit public key prefix would bring that down to 12 ms.

@cuchaz Another benefit is that keys are small and unstructured. Any 32 byte string can be converted to a key via some bit-masking—you create them from random data (or a hash output). So the keys are fast and simple to generate, they're small, and they can be readily derived deterministically from a passphrase if you're into that sort of thing. (And if you have both X25519 and Ed25519 keys, they can both come from the same shared seed, with a bit of context separation for safety.)

@cuchaz There's some truth to that. For instance, the top post-quantum schemes seem to have pretty large keys, which might violate some protocol assumptions.

But they also might just work really differently in ways that don't match either RSA *or* ECC. Think of how ECC relies on key exchange rather than RSA's traditional asymmetric encryption, and doesn't have a notion of unifying encryption and signing. It seems to me there's a not-inconsiderable chance of further fundamental changes in the available primitives. Without being a serious cryptographer (let alone one who is up-to-date and has an eye for trends) it's impossible for me to make that kind of prognostication, though! I think keeping an eye on later versions of the protocol being able to swap out cryptosystems at a lower level makes sense, but I feel like it would be easy to unduly constrain the overall protocol.

(That said, all of the round-4 NIST PQ submissions appear to describe KEMs, making them more similar in shape to public-key ECC than to RSA, if I'm not totally misunderstanding things.)

OK, here we go: A way to inject a string value inside a #YAML string in #Helm chart templates!

You won't like this.

"... {{ $someValue | quote | substr 1 (int (sub ($someValue | quote | len) 1)) }} ..."

I promise you that this is one of *less* terrible ways of performing this extremely fundamental operation.

EDIT: Good news! I've golfed it down to just two function calls:

"... {{ regexReplaceAll "^\"|\"$" (quote $someValue) "" }} ..."

This quotes and escapes the value, then uses a regex to remove just the beginning and ending quote, and finally interpolates it into the larger double-quoted flow scalar.

#YAML is endless fun.

@feld Yeah, but the templating language also doesn't give you a way to interpolate into a JSON string. :-/

Today I have experienced the horror that is #Helm.

Helm chart templates make #Kubernetes manifests by string-templating #YAML.

YAML has one of the most unfriendly syntaxes of any textual data structure language I've ever seen. There's a whole website just dedicated to the nine different ways you can write a multiline string.

And Helm just... string-interpolates values into it. The most fragile syntax in the world, and you're just going to inject raw bytes straight into it. The only tool provided to alleviate this is the `quote` function, which... doesn't actually do what you want.

Currently at work I'm trying to figure out how to insert an arbitrary string value into another string, which is a pretty normal thing to do. And four attempts later, nothing works. The most common "solution" on the web appears to be to use `{{ ... | indent 12 }}` where 12 has to match the template's current indentation level. Good luck if you ever want to reindent anything!

@lopta I reset my password using the "compromised account" feature, since it just took a moment. Little to lose. However... I'm not convinced yet that there's a legitimate threat, so I haven't done anything beyond that.

(I don't use 2FA with Amazon because their 2FA support kind of sucks, and I don't have any "devices".)

It's easy for people to think they've found something serious and be dead wrong about it. I know this from the perspective both of someone who has raised a false alarm, and of someone who has to field security disclosures. So I'm holding this with some uncertainty, and I figure we'll know soon enough.

@Cloudguy @feld This is quite a rude response to a reasonable inquiry.

You're making some grand claims, and leveraging limited social capital to do so. (I've never heard of you, and you haven't made it easy to verify you.) Posting insults is not making it any easier to take your word on faith.

@Cloudguy @topher It's at least a little bit vague. :-) I used to have the same login for the ecommerce and AWS sites, but I don't any more; I don't recall what happened, but I think they've separated them, or encouraged people to separate them.

For people with *AWS-only* accounts, does anything need to be done? Because that's the bigger lift.

@pettter @Weld Not here—they used a randomized controlled trial.