PKCS7 is a container format that pops up in a couple places in the TLS ecosystem (also in code signing); anywhere you need a secure blob that includes metadata. It's a very widely used format.
AEAD ciphers are those that simultaneously encrypt and authenticate data. AES-GCM is the most popular; Chapoly is the 2nd most popular. AEAD ciphers are how modern programs do encryption.
AEAD ciphers all rely on additional parameters, most commonly a nonce; it's critical to security that the nonce only ever be used once with a given key. You need the nonce to decrypt the AEAD ciphertext, so it's usually tacked on to the message (in more clever formats you can derive it contextually, but PKCS7 is a general-purpose format).
In parsing PKCS7 messages, when OpenSSL comes across AEAD-encrypted blobs, it needs to parse out the nonce. AEAD nonces tend to have fixed sizes, but there are extended-nonce variants of AEADs, and the format allows for arbitrary-sized values. OpenSSL assumed a fixed nonce size, but parsed with a library that handled arbitrary-sized values. Stack overflow.
A maliciously formatted Authenticode signature, certificate chain, OCSP response (I think?), all things that could trigger the bug.
This is PKCS#7 (well, CMS) encryption, not signing, the only places you're likely to find that is in S/MIME encrypted (not signed) email, and how often do you see that used? In theory other protocols that use CMS as a container format like SCEP could be affected, but that doesn't do AuthEnv. It also signs the encrypted data so the attacker would have to be the authorised/trusted party you're communicating with. There's also CMC, but that doesn't do AuthEnv either, although one of its infinite options does allow for unsigned encrypted data.
Services that process CMS[1] or PKCS#7 envelopes may be vulnerable to this bug. The most common example of these is S/MIME (for signed/encrypted email), but PKCS#7 and CMS show up in all kinds of random places.
(Unless I'm missing something, a key piece of context here is that CMD/PKCS#7 blobs are typically allowed to select their own algorithms, at least within an allowlist controlled by the receiving party. So the fact that it depends on an AEAD-specific parameter encoding is probably not a huge hurdle for someone looking to exploit this.)
Monopolies are made illegal because they limit consumer choice and the role of competition in the free market, distorting incentives.
The status quo has all of the problems of a monopoly. Doing this or not doing this won't change that. But it will remove another barrier to consumers being able to do what they want.
I care about the web remaining a truly open platform based on standards rather than the whims of a singular software project. What matters is browser diversity, even if it's at the expense of browser choice. Because without healthy browser diversity, the web might as well be renamed the Chrome Protocol and you lose browser choice anyway.
Apple, with their iOS browser lock-in, is the greatest gift ever to the open web.
No, the status quo has the problems of a whole series of interconnected monopolies. More than one will need to be broken up before we are out of it, but one step at a time. I'd be surprised if chrome is still part of google when the politicians have reached a happy state.
Google has an incentive to make everything work through the web. Safari has the incentive to gatekeep the app store revenue, which is why PWAs are a joke on iOS.
Google also has bad incentives (Android, ads) but Safari is the IE6 of modern web.
It depends on what you are looking at. Chrome is the IE6 of the modern web as far as it is often the only browser people care about, but it's very much the opposite of IE6 regarding developing new features and moving web tech forward. In order to have a productive conversation about which browser is the new IE6, I think it's important to state what you are measuring
it's the browser you need when your shitty default browser decided to spend their money elsewhere instead of building a proper browser that can compete against the app store lock in
If anyone is building using experimental features that are either flagged or unflagged in Chrome, that's NOT on Chrome. For example, if I built a feature based on Chrome's weird Observables, sure, I could do it... it would work nowhere else. If you're actually seeing this happen, who do you blame in this situation?
IE flat out refused to implement features that were agreed upon by standards bodies. They pushed for VML development and ignored SVG. They ignored CSS3 in favor of their DirectX filters. Chrome does indeed put experimental features out there AFTER they support the standards. Firefox also has agreed to a set of web standards and is simply behind on implementation.
Having lived(as a developer) through IE4 - IE9, I reserve that title of "the new IE" for the worst offenders.
The web gives users a lot of control using extensions. That's why companies don't like it. Google tries to fight it by not supporting extensions in its mobile browser. Apple is more egregious, preventing people from doing many things using the web platform entirely, with no escape hatch.
Much better but only slightly more popular. Partly because the Play Store ecosystem treats wrapping PWAs as a first class use case and you don't even have to source APKs from the official store anyways - so there's not much to gain by delivering via "true" PWA. Apple goes more the route of the stick than carrot.
This is an understandable concern, but it's not actually supported by the data.
On MacOS, where there has long been engine choice, Safari market share is >50%. Defaults are powerful and many users are happy with the real and perceived benefits of the first-party brand.
Safari has >90% market share on iOS today. If engine competition were permitted, they might lose a few percent initially, but would be highly motivated to close any gaps.
There's no world in which WebKit usage among the world's wealthiest consumers drops low enough that web developers can target a chromium monoculture. The purpose of engine choice is to create real competition in order to motivate Apple to do better.
It is shame that this is true. However it should not mean that we need to accept this situation. Hopefully Google anti competitive practices with Chrome can be addressed at the same time.
Those popups I get multiple times a day about how this website works better on Chrome , which cover half my screen and which forward me to the App Store, are incredibly misleading. I have misclicked many times and then the App Store opens up. If you go back to the browser and hit the back button, it will again open the App Store. I have to press and hold the back button and skip multiple pages to get back to what I was doing.
Maybe that wouldn't be the worst thing. Maybe chrome capturing the majority of the iOS market would finally be the proverbial straw that breaks the camel's back and pushes regulators towards forcing Google to sell Chrome.
Or… Sundar Pichai has lunch with Trump, brings with him a few nice cigars and a Google-sponsored Yacht (I hear he’s still short on these), explains to him how that’s all just a liberal media fake news campaign against good American products, and they decide to axe regulatory bodies instead.
Maybe when all browsing is under one monopoly then we'll finally care to regulate it properly instead of sticking our fingers in our ears and saying we have a different monopoly for iOS users so everything is fine.
I don't disagree, but this is an "ends justifies the means" type of argument, which generally speaking I struggle with. I think sometimes the end does justify the means (within reason of course), but I try to be very cognizant when that is the position.
I do also think there are a lot of downsides to letting big tech companies exercise tight control over stuff, especially when it is anti-competitive. The slowing of Chrome is a good outcome, but there are plenty of other downsides that come along with allowing Apple (and others) to have these policies.
Unfortunately, the problem is that what's needed is for a massive special antitrust operation to address the tech sector as a whole, unravel all the various anticompetitive, bundling, and otherwise monopolistic behavior they all engage in, and implement remedies on all of them at once.
But the US's system certainly doesn't allow that (and, of course, there isn't going to be any serious antitrust in the US for the foreseeable future anymore). I have no idea if the EU's does, but I really don't think they have sufficient jurisdiction to do things like break up Apple, Google, and Microsoft. Which is definitely necessary to address these problems.
Make no mistake: the reason we are here is because of the morally- and intellectually-bankrupt shift to the Chicago School-backed philosophy of antitrust under Reagan, coupled with a government—at all levels, in all branches—that didn't understand technology, and collectively refused to learn, for decades.
If Chrome has a full monopoly, guess what's the next logical action...
Might as well get it over with quickly.
In case it's not obvious, these crutches should be removed.
Treat Google paying Apple for the use of Google's search engine and Mozilla for the same thing, as anti-competitive (they're token gestures propping up the monopoly).
And break Google up in multiple companies. Not sure along which lines but I would steer towards platforms (Android + Chrome + Search + Docs + Cloud; banned from entering advertising), Play Store, Ads.
The same thing should be done to Apple, Microsoft, Amazon, etc. Nobody has the guts anymore.
I think nobody has the manpower to deal with all the shit. The EU already regularly fines big companies, but for every fine they get away with so much.
We're very careful, it's not being removed even after blatantly illegal actions, and even then the mandate isn't global, and we've waited for many years.
It's a fairly obvious truth. Chrome has a 70% browser marketshare, with the only appreciable alternative being Safari. If Chrome (the actual Chrome and not just a skinned Safari) were allowed on Apple's platforms, overnight a crapload of websites would throw a "Made for Chrome" banner up, dismiss anyone on "unsupported" browsers, and we would rapidly move to a Chrome-only world.
We already went through this in the IE era, and it was an ugly period. We don't need to do that again. That isn't to say we need to endure the status quo, but we are in a dangerous situation where the fixes aren't easy or obvious.
You're literally defending a megacorporations monopoly and abuse of users so they can continue denying free choice to people using phones.
You're literally saying that the browser the users are right now forced to used by a megacorporation is so bad, they would refuse to use it in the future. And then you double down on the bootlicking by demanding that they continue forcing the use of their supposedly inferior product.
(After all, if the product is actually good, why would people switch?)
And with that you're entrenching megabillionare interests and outright banning creation of opensource.
It's the unfortunate truth. Nobody gives a shit about Firefox, not even Mozilla. Safari is the only major non chromium browser. You get rid of it and Google basically has full control of web standards and we've come full circle.
I use Firefox because it is the only mobile browser worth a damn. Mozilla screwed up by wasting resources on FirefoxOS and other projects that had no business case in the early days of mobile browser adoption, but they eventually got their act together and started supporting extensions and other differentiating features that people want. They're still slow-walking container support, but nobody else has that either.
I daily use Safari on MacOS and iOS, and regularly use Edge on MacOS and Windows 11. I really don't notice a difference, other than I find the dev tools in Chromium browsers more familiar and overall better.
Brother, I have no idea what you're talking about. I feel like it's gotta be some high concept trolling lampooning the spirit of the average Hacker News but I don't have the energy to read your comment history and find out.
This link does not exist right now, but it will allow EFF to take control when necessary. E.g. by nudging people away from Chrome if it becomes too powerful.
Of course if a browser does not faithfully execute the code that it is given, that will be a next level of anti-user behavior and might cause an uproar that will make people walk away even faster.
In the actions overview, just the spinner icon (svg w/ css animation) takes 25-40% cpu and 10% gpu in my chrome. Enough to keep my fingers very warm on the laptop
no, they have very low quotas by default, and you have to request increases through the portal, which then get rejected and you click the button to contact support/email and then you sometimes have to negotiate with them
you have to do this for every single instance type they have, can't even experiment or test other instance types cause its too much trouble to get quota
The comment I replied to was not talking about changing quotas but actually creating instances.
> Yes it’s weird that you have to ask them for instances which some actual physical person looks at your request, thinks about it and says yes or no to.
"The broader security issue being addressed is Intel SA-00532 that could lead to a denial of service by authenticated users due to insufficient control flow management"
Not really. It'd be more accurate to say it's a workaround for an existing proper hygienic macro system built on static introspection and code generation.
Not really. It's not a workaround - it just works.
Maybe most uses of lexical macros could be done with hygienic macros / macro replacement bodies that are fully formed expressions (AST nodes), but not all of them.
For those macros, really the "hygienic" doesn't matter half as much as people pretend. Don't do complex macros where the "hygienic" is required. Don't generate code, write code. If you need to generate syntax to remove boilerplate, then sprinkle a few macros in. But to generate syntax, in general you'll need a lexical macro system.
I'd say its not really a workaround, its a feature. And a hard one to use well. But as someone said in another comment, i think reading the preprocessor in C and especially C++ with the templating is really interesting and help a lot understand how the OG team behind the code used to work. Some tricks are "too clever" for me originally, but with proper documentation on these tricks, i understand tehm and sometime, i have a sudden hindsight/sudden clarity (i don't know how to say it, its a bit like entering the zone?)
How is a straightforward solution to some development problem (create multiple language entities, like enum + data tables, from a single point of definition in the source code) a workaround for some lacking thing?
Maybe you could clarify by posting a better version of what GGP suggested.
"Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable"
to human?