Yeah something like 10-15 years ago I thought for just the simple action of printing a file, it was way easier in Ubuntu than Windows, simply because they included a lot of drivers in the distro by default, while in Windows land I still had to visit the printer manufacturer's website for drivers -- or use the included CD! I try to avoid needing to do anything more complex than that. (Scanning I've always done with a USB stick plugged directly into the printer.) Things kind of got worse again in recent years with the removal of the standalone GUI for administration in favor of a web interface, and various ongoing modularization efforts, in theory cups3 will work even better and only support IPP/AirPrint: https://openprinting.github.io/current/#the-new-architecture...
at least for awhile this is how bluesky/atproto worked. afaik they only ran into issues when the number of users on each server overwhelmed how many files would fit comfortably in a single directory (which is obviously a large number)
my understanding matches yours. I don't think this article is particularly clear about why rapid7 would threaten to disclose a vulnerability before a patch is ready and then subsequently get angry that jetbrains put out a patch to fix the issue
so rapid7 is mad that jetbrains fixed the vulns they reported? isn't that the point of reporting vulnerabilities? why is rapid7 threatening to release the details in 24 hours?
> Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them.
So JetBrains wanted to have a patch ready before disclosing the vulnerability publicly. It seems they were working on it and were working with Rapid7. I am struggling to think how it would be better for users if an unpatched vulnerability is released before a patch is available. What's the thinking here, that users will take additional precautions to secure the application while they wait for a patch?
> Rapid7 spotted fresh patches for CVE-2024-27198 and CVE-2024-27199 on Monday, without a published security advisory and without telling the researchers.
Rapid7 reported the vulnerabilities mid-Feb. Jetbrains turned around with patches about 2 weeks later, and published them yesterday. The CVE was literally created yesterday. Isn't it a bit premature to claim "silence"?
They released patches without saying they were related to a vulnerability and without notifying Rapid7. That is the textbook definition of what a silent patch is.
I'm not sure how to reword it in another way that would help you understand that Jetbrains did what is called "silent patching".
Maybe this paragraph from the article makes it clear?
>Rapid7 claims that after more than a week of radio silence from JetBrains on the coordinated disclosure matter, Rapid7 spotted fresh patches for CVE-2024-27198 and CVE-2024-27199 on Monday, without a published security advisory and without telling the researchers.
That makes this whole thing fall under Rapid7's silent patching policy.
Above I linked to a blog post Jetbrains put out on March 3rd, on Sunday. It details the vulnerability. March 3rd is before March 4th, so it seems they did not silently patch anything but published the patch and details concurrently.
And this is the part Rapid7 presumably took issue with.
>At this point, we made a decision not to make a coordinated disclosure with Rapid7
As well as
>We published a blog post about the release. This blog post intentionally didn’t mention the security issues in detail
Which is presumably the blog post that Rapid7 saw, which triggered their silent patching policy.
Although, after reading all the blog posts (from Jetrbrains, and from Rapid7), I think this is a much more standard affair than The Reg tries to spin in its article.
the context is "yes, you were down by 14, but your team just lined up and scored a TD on the last play. you have to make the decision whether to kick the XP or go for 2. since you just scored 6, you are now down 8"
it is confusing because the conversation is taking place after you just scored
these are the assumptions they are attempting to debunk:
- All 2-point conversions are equally likely to succeed.
I have seen no evidence that all 2-point conversions *aren't* equally likely to succeed, and even if they were two bites at that apple gives you better odds than just one
- You will stop the other team from scoring.
regardless of whether you choose to go for it or kick the XP, you still have to stop your opponent on their subsequent drive. if they do so much as kick a FG it's game over already, so it doesn't matter.
- You will get a touchdown on the subsequent drive.
you have to score a TD or the debate doesn't matter so it's irrelevant to this argument
- The clock expires after that.
again we have to assume we are preventing the opponent from scoring any additional points because the debate makes no sense without that caveat
- There are even odds of winning in overtime.
getting to OT in this scenario is the fallback, while it's the best outcome of just kicking the XP twice in a row
Surely implicit in the statement is "all 2-point conversions in the 4th quarter by the same team" since we are comparing 3 possible 2-point conversions in the 4th quarter by the same team. (2pt conversion when down by 8, 2pt conversion when down by 2, 2pt conversion when down by 1).
you're planning around the time where most of the people who review these things are going to be taking PTO. as far as I could tell reading the guidelines the only guarantee apple gives you is that they'll get to it as soon as possible
it's also a little funny that DHH is saying that apple exempted them from the rules last time and then a couple paragraphs later is complaining that apple exempts other companies from the rules as well
Anyone who has ever deployed an app to the iOS App Store knows, very well, that Apple slows reviews during the US Holiday season. Additionally, anyone who has done this also knows that Apple review times are extremely variable from 1 day to 1 month.
I agree, the duration of the review is irrelevant to this complaint. I would suggest hiring SWEs/consultants who actually understand the iOS App Review process the next time you want to release an app, since Hey obviously does not understand it.
Correct, but anyone with experience attempting to release during this timeframe knows that review times between Thanksgiving and the new year are always slower than normal.
Additionally, brand new apps, not new versions of existing apps, always take longer.
I constantly recommend to both my project team and other teams asking for advice to have a submission in to the App Store 4 weeks before you want to release. Otherwise you risk exactly what happened here.
Apple preemptively warns developers about longer processing times during the holidays every year. (Until recently, they did no reviews at all during the week of Christmas.) E.g., https://developer.apple.com/news/?id=xpkhwg3l
>it's also a little funny that DHH is saying that apple exempted them from the rules last time and then a couple paragraphs later is complaining that apple exempts other companies from the rules as well
The author wants clear and fair rules so that exemptions are never even needed. I think the article is pretty clear on this.
Getting their exemption was an absolute nightmare for them - It’s certainly not something they are gloating over.
Hey didn't get special treatment. They got the published rules changed in regards to ALL E-Mail apps. Not just theirs. And they clearly show the resulting policy update in this post. That's not special treatment. That's progress.
I'm not sure why it deviates from Debian and Ubuntu which its based on though
reply