Imagine how refreshing if the press release simply said:
"We over-hired, we're ram-packed full of managers pinging each other on Slack all day and need to cut costs to sustain our operation. We think GitHub's shit and we want to be a nimble org with a fighting chance at eating their lunch. We're also gonna provide 1000 free runner hours/mo to open source projects that move from GitHub to gitlab, and we're gonna make project namespaces on gitlab.com a first class thing like GitHub did"
This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...
1) Package owners will often realise they've been hacked quickly, since there are releases they never authorised. This gives them plenty of time to raise the alarm and yank the packages
2. Independent security researchers and other automated vulnerability scans will still be checking the latest releases even if users aren't using them
Yes it's not a perfect defense but it would help a lot.
These malicious packages are being caught by the authors, and by automated package security scanners, not just by end users. npm should start setting this 7 day cooldown as default.
Some people would set up tooling to look for compromises the moment they get published. What's neat about this is that as an attacker you have no way to determine beforehand whether you'll get caught by this. So you would run your attack, it would lead to a compromised package being published, then the world would get a chance to look at it and see if they can detect the issue with it. This would of course lead to attackers being a lot sneakier. But I think due to the opaque nature of what checks people are running against packages and what they might notice, a much smaller number of attacks would make it through. Of course the ones that did by definition would be the ones that were impossible to detect and would thus stick around a lot longer.
you are betting that the package is popular, has enough eyes to mitigate attack in 7 days. attackers could also target unpopular packages for long game
Same everywhere: avalanches of AI garbage and intellectual dishonesty. People claiming "I wrote this", then a look at the code shows massive slop and an author with no clue about the topic.
More worrying, this trend is creeping to all domains:
"Nearly 75,000 tracks uploaded to Deezer are fully created using AI. That’s 44% of daily uploads, and more than 2 million per month. Back in June, the daily number was around 20,000."
You need to seriously look at your corporate communications and hire some adults to standarise your messaging, comms and signals. The volatility behind your doors is obvious to us and you'd impress us much more if you slowed down, took a moment to think about your customers and sent a consistent message.
You lost huge trust with the A/B sham test. You lost trust with enshittification of the tokenizer on 4.6 to 4.7. Why not just say "hey, due to huge input prices in energy, GPU demand and compute constraints we've had to increase Pro from $20 to $30." You might lose 5% of customers. But the shady A/B thing and dodgy tokenizer increasing burn rate tells everyone inc. enterprise that you don't care about honesty and integrity in your product.
I hope this feedback helps because you still stand to make an awesome product. Just show a little more professionalism.
Think about integrating calendars, corporate contacts (from AD), handling RSVP replies said mx server receives and updating the calendar server, securely deal with modern auth (+ legacy krb5 auth, yuk). It's a huge hassle and everything except Exchange only handles 80% of this.
Modern expectations now want: web clients (OWA), todo lists, integrated storage (SP/OneDrive), and push notifications to any phone from any vendor.
So yeah, the only on prem solution is still Exchange.
I don't think these things are as important as you think.
RSVP for example. Nobody read or cares who and what people reply. In the last 4 companies I worked for (including one in Switzerland), nobody cared if I accepted or confirmed my attendance to the meeting and would try to call me/force me into a meeting even when my status showed I was on another shsring my screen. And nobody seems to respond nowadays nor check calendars for availability and avoiding conflicts.
But what about push notifications to mobile? I'm not aware of anything that handles this as well as Exchange ActiveSync. it's reasonable that you get an email within sub 1 minute latency, not 15 min polling.
The IMAP protocol has an IMAP IDLE extension for that purpose.
But is that use case really common in practice? With chat tools people don't tend to use email for instant messaging (well, appart from deltachat users, which can be a solution too!) and my experience is that it doesn't even work like that / that well for office 365 users. I am regularly told on teams that an email has been sent to me (same org and same region) yet it still takes more than a couple of minutes to have it visible on my desktop outlook client.
if you dont mind asking, what dont you like about kerberos? I personally like it quite with certs / hardware token
to be honest, most things you list can be setup with some research. The only one I am not sure about is integrated storage, but then I am also not entirely sure what that even is supposed to mean exactly
The user experience between a phone, tablet and computer should be symbiotic. Krb is not a first class thing in the mobile world. So users now hav great Krb experience with Outlook.exe but are typing passwords into Safari at owa.example.com (anywhere you type an AD password that isn't lsass or ADFS is really not good posture)
So, passwords are bad and the password is a key component of krb. Moving away from passwords is a step in the right direction eg OIDC.
right given the product names I assume you are on windows. with kerberos people shouldnt have to type their passwords into apps at all, and if you use pkinit there are no passwords at all?
i give you the mobile part, I dont know how well it is supported - iOS claims to have support though, and android through third parties I believe. Never tried that. Its just that I personally have a preference for auth methods that dont require opening a browser for desktop apps
I find the style of writing incredibly annoying (it doesn't make the point, full of hyperbole) and the website has the standard slopsite black background and glowing CSS.
"We over-hired, we're ram-packed full of managers pinging each other on Slack all day and need to cut costs to sustain our operation. We think GitHub's shit and we want to be a nimble org with a fighting chance at eating their lunch. We're also gonna provide 1000 free runner hours/mo to open source projects that move from GitHub to gitlab, and we're gonna make project namespaces on gitlab.com a first class thing like GitHub did"
reply