Hacker News new | past | comments | ask | show | jobs | submit | cbarrick's comments login

The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets.

Edit: foot successfully inserted in mouth


I wrote the "PGP Problem" article and definitely was not just talking about "the format of individual packets", which you might be able to tell from the fact that it brings up a quadratic parsing DoS in that design as well.

Since you are the author of TPP could you please explain how your example shows some sort of quadratic parsing DOS? I don't see anything like that. Just a huge number of signatures.

The postmortem on that DoS attack was at pains to point out that they were "officially" documenting only one of the vulnerabilities. Somewhere on an old drive I have the giant mountain of mailing list posts I sorted through to write that post, and I may dig it out at some point, but right now you're just going to have to take my word for the fact that I was not suggesting that the only problem with the packet format was the fact that you can represent lengths 8 different ways.

This is a deeply silly discussion to be having on this particular thread, which, again, is about a vulnerability that owes to the PGP packet format.


An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes...

The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").

Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853


When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false.

Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:

- The message grammar validation was incomplete, as mentioned

- The streaming decryption/validation code affected how the packet sequence was processed

- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when

- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)

All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.


What you're seeing me and 'woodruffw implying is that modern formats are (deliberately) trivial to parse. OpenPGP is not. That is a security design feature that OpenPGP lacks, and it's a big one, because it's caused multiple issues already.

Yes, I understand and never said I disagree with that :) I'm just trying to provide some nuance and background about the specific issue discussed in this submission, as IMHO I think it's more interesting than making the same high-level points about OpenPGP over and over in every thread related to it (no offense meant, of course).

This just looks like reStructuredText.

Quarkdown:

    .somefunction {arg1} {arg2}
        Body argument
rST:

    .. somefunction:: {arg1} {arg2}
        Body argument

This page consistently crashes on Vivaldi for Android.

Vivaldi 7.4.3691.52

Android 15; ASUS_AI2302 Build/AQ3A.240812.002


You should read more about Markov Decision Processes (MDPs) and Game Theory in general.

The word "solve" is well defined in this context, and is used accurately by OP. You "solve" a game by finding the policy that maximizes the expected return.

Obviously we can only talk about "expectation" because the outcome is random. But that doesn't mean that an optimal policy doesn't exist.

Optimal policies are also often random, expressed like "in state S, perform action A with probability P and action B with probability 1-P". A policy then boils down to a table, with a row for each state and a column for each action, where each cell is the probability of performing that action in that state.

Even more interesting are partially observable Markov decision processes, where your agent doesn't even know what state it is in. Instead, you get observations that hint to the true state, and you model the state as a probability distribution over possible concrete states. Solving these POMDPs is quite a bit more difficult than traditional MDPs.

It is possible to solve some MDPs (and POMDPs) by hand, but in practice we often use reinforcement learning to learn the policy table by simulating games.


One of my many probably-going-nowhere hobby projects is a modern Prolog. I think the module system especially is a place where we need innovation.

I'd like to see someone do for Prolog what Clojure did for Lisp.


what Clojure did for Lisp

Hickey’s goal was improving JVM programming ergonomics. It was not changing Common Lisp (or Scheme).

Sure, Clojure exposed some programmers to lisp, but lisp shops didn’t convert to Clojure. JVM shops did adopt it in part because Clojure “is just a Java library.”


Which is why the Clojure community is the coolest from guest languages on the JVM, as they embrace the platform, instead of dissing the platform like the other one used to bootstrap a mobile SDK ecosystem.


Not entirely wrong, but … only one of Clojure and Kotlin is close enough to Java that it’s inspiring meaningful improvements in the upstream ecosystem. If the “dissing” hypothesis were true I’d expect Clojure to be the one influencing the most change, but it’s not.


Oh boy are they so true, one of the reasons I don't care about the Kotlin Virtual Machine any longer.

So full of themselves on how much better they are than Java.


Imho, Scala is the coolest of the JVM guest languages :-)


The language yes, the way the community embraces the platform and ecosystem that makes their existence possible in first place, not as much.


What do you consider as 'embracing the platform and the ecosystem'? As far as I'm aware Scala is fully interoperable with anything on the JVM.


Community, I wasn't talking about the language itself.

It puts me off having a programming language that depends on the Java the Virtual Machine, Java the programming language, Java the ecosystem, so that their language could exist in first place, and then talk down on it.

Still waiting on Scala Native or Kotlin Native to take over JVM and the standard library.

Clojure community isn't like that, while they try to stay on Lisp like land, they embrace the ecosystem (JVM and JS), without putting it down at every opportunity.


How can Scala 'talk down' the platform it exists on? This doesn't even make sense. You know the creator of Scala made deep contributions (generics) to the JVM, right? Scala's sbt is used by many Java projects as a build system. Its Play Framework and Akka actor system are super popular in Java too because they provide idiomatic Java APIs. Projects like Spark keep JVM relevant for Big Data. SoftwareMill's Ox project builds directly on top of JVM virtual threads and structured concurrency. I haven't even heard of any equivalent Clojure project.

You have it exactly backwards, I'm afraid.


The community, do I have to letter spell you, why do you keep talking about Scala the language, Scala projects?

Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology, its limitations and warts, how it prevents the language greatness, that by accident happens to be the underlying infrastructure of their beloved language?

Do you rather have links to discussions on Reddit, Twitter discussions and what not?

I never said anything about the creator specifically.


> Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology

There are always a few loudmouths in every community, you are making the classic mistake of judging everyone by that same brush. Most people using Scala are using it exactly because of the JVM, otherwise what's the point? There are great languages on other platforms too.

A few people use it to push the boundaries of what's possible on the JVM, and it is thanks to these people and the Scala team themselves that the JVM continues its evolution and the Java language continues to acquire more Scala-like features. It's not a zero-sum game, everyone is benefitting here.


Yep. The parallel here would be taking logic programming and opening it to new users. Prolog or systems like CLIPS are super powerful and map to common problems better than other tools, but are Scary and Niche and Unknown.


Do look up annotated logic: https://www.sciencedirect.com/science/article/pii/0743106692... as e.g. utilized by https://github.com/lab-v2/pyreason which is the best summation of the various fuzzy logics more modern prologs experimented with


20 years ago I had the same thought. I actually started implementing the Rete algorithm. Midway through I realized, “hey, this is just relational algebra. May be I can integrate it in a relational DB engine. Use rows in tables as facts and materialized views as generated facts.” It soon spin out of scope and I lost interest. Later I did use what I learned to build a rule based event processing engine.


I still have a fanfold printout somewhere of the OPS5 implementation I wrote in C, back in the 80s :-)


Same here. Remember when we called our AI "Expert Systems"?


That's amazing.


It's not the same flavor of logic language but I've been trying to find some interesting things to do in Curry. The functional dependency component it introduces makes some problems a lot easier to deal with in Curry than in Prolog (or at least that's what someone told me one day....)

The project as a whole exists and everything, but even things like just having an easy-to-install implementation on Homebrew hasn't happened yet, so if you're up for some sweat and tears and low hanging fruit, it feels right to me!


MKL is usually what you want if you are doing matrix math on an Intel CPU.

A better design is to make it easy you to choose or hotswap your BLAS/LAPACK implementation. E.g. OpenBLAS for AMD.

Edit: To be clear, Netlib (the reference implementation) is almost always NOT what you want. It's designed to be readable, not optimized for modern CPUs.


I would argue that BLIS is what you want. It is proper open source and not tied to Intel platforms.


It would also explain it for non-emacs users.

I am not and never have been an emacs user, yet I still know of org-mode.


I've heard of it many times, but have basically no conception of what it actually is.


It's a file format / markup language (think Markdown but more feature-rich) with excellent editor support in Emacs.


That's like describing a swiss army knife as a "beer opener"


I think the explanation "you’ll end up exhausting your own resources" is wrong for this case. I think you are correct that the bots are simply too dumb.

The likely explanation is that the bots are just curling the expensive URLs without a proper JavaScript engine to solve the challenge.

E.g. if I hack a bunch of routers around the world to act as my botnet, I probably wouldn't have enough storage to install Chrome or Selenium. The lightweight solution is just to use curl/wget (which may be pre-installed) or netcat/telnet.


XLA (Accelerated Linear Algebra) [1] is likely the library that you'll want to use to code for these machines.

TensorFlow, PyTorch, and Jax all support XLA on the backend.

[1]: https://openxla.org/


My public repos on GitHub are not a good way to judge me as a candidate. Not even close.

Frankly, I don't have much time to contribute to open source these days. I send a PR maybe once a year.

Almost everything on my profile is from my university days, and none of it is related to my career specialty (ML SRE).

And my employer asks me to fill out a form before I publish personal projects, so that they can be sure it is unrelated to my job (and thus that they do not have a patent or copyright claim over the code). This means most of my weekend projects simply aren't public, because I can't be bothered to do the paperwork.

LinkedIn, on the other hand, clearly shows where I've worked and what I've worked on. It's a much more accurate resume for me that GitHub.


Same here. I don't care to publish my personal projects on Github and my work projects aren't there for obvious reasons.


I think a tool like this would be targeted more towards eliminating false positives, rather than eliminating false negatives.

I think this tool as a whole is probably an awful way to judge a candidate. But that's not really the point. The point is to find additional candidates with a low false negative rate.

E.g. over the past year I've written tens of thousands of lines of zig code. But that's not on my resume nor my LinkedIn. this would allow someone to include me. Is the code good, or am I a good candidate? Impossible to tell... Ah, but now you have heard of me! :D

There's more fluff on the page, but it's just fluff, and safe to ignore.

> And my employer asks me to fill out a form before I publish personal projects, so that they can be sure it is unrelated to my job (and thus that they do not have a patent or copyright claim over the code). This means most of my weekend projects simply aren't public, because I can't be bothered to do the paperwork.

Your employer is bad and they should feel bad! If you have the option you should consider changing to an employer less willing to make the world worse... or maybe a jurisdiction where that toxicity is unenforceable.


> Your employer is bad and they should feel bad!

For the record, my employer is Google.

They call this process the Invention Assignment Review Committee or IARC.

From what I understand, the process is not actually enforceable anyway. Code I write related to my job is owned by them; other code I write is owned by me. I don't necessarily have to go through their process for this to be true. And their lawyers certainly know this.

I've done it once, and the process is lightweight. And I probably could ignore it in practice with no one actually caring. But the fact that the process even exists is enough of a blocker that I don't readily publish my hobby projects anymore, and that's kinda shitty.


> I've done it once, and the process is lightweight. And I probably could ignore it in practice with no one actually caring. But the fact that the process even exists is enough of a blocker that I don't readily publish my hobby projects anymore, and that's kinda shitty.

and they know this, and that's the point... there's a reason people talk about the chilling effects of shitty, but not technically illegal behavior

> For the record, my employer is Google.

Yeah, I knew that from your hn profile. Which caused me to ask a friend, also SRE at google, how onerous it was, he said basically the exact same thing you did, just intrusive enough his github is also completely empty.

I wonder what cool stuff doesn't exist today because of it


over the past year I've written tens of thousands of lines of zig code. But that's not on my resume

why not?

i have included every significant contribution to any project, whether it is paid or not on my CV. why would i leave that out? it's experience. only code that i write for my own use and don't publish may not be worth to be listed


Because it's across a few projects and none of them are popular enough to be worth listing.


Yes, I'm in the same situation. The majority of my work is on private repositories, even though I've contributed to public repositories for many years. This tool wouldn't accurately reflect my current skills.


Then clearly you would be ranked very low by something like this. I think that is the whole point of this: tell the people who have solid commit history from those who don't.


But the ranking is not reflective of actual skills. That's the critique. Aside from very frequent open source contributors (and I think these people are the minority of devs), devs will tend to be "profiled" by this tool according to the dot scripts, university projects, Advent of Code, or other half-hearted projects they happen to have put on their Github. (Maybe I'm just projecting...)

The issue isn't that not everyone has a Github presence, the issue is that for most people their Github presence is somewhat unrepresentative of their actual job skills.


It is one dimension of many showing amounts of practice. I understand why that makes people sad, but that sadness just feels narcissistic.


I might be interested on people who can help me solve my particular problem. Those people might not be the same who have lots of commits on Github.


Then, logically, you would not hire them solely based on this one tool.


I completely understand your situation. GitHub isn't the perfect fit for everyone, especially for those in specialized roles like ML SRE

GitMatcher is primarily aimed at the sourcing stage, where recruiters can find devs based on their actual code contributions. But I agree, it's not a one-size-fits-all solution — it's not meant to replace LinkedIn or fully capture your career.


I think the problem runs deeper than that. What you’ve done is an interesting tool for finding out more about a relatively small slice of developers.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: