|
well the tooling is heinously dumb for defaulting to "sure why not grab anything 'newer' (by convention of semver), that sounds good", but even in general the security of these dep managers isn't covering the threat model of "bad actor injects a malicious package as a dependency" it's been a theoretical threat for a while but has taken a surprisingly long time to play out in practice.
|
# ? Jun 25, 2019 12:01 |
|
|
# ? Jun 8, 2024 09:27 |
|
Enforcing that a minor update doesn't contain breaking changes is analogous to enforcing that an API implementation doesn't contain bugs. You cannot reliably automate it, otherwise a big chunk of us would be out of a job, but you can clear some big low-hanging fruit. The Elm package manager enforces that the API surface cannot change in a minor patch; any and all package managers for statically-typed languages should do the same. Going further, you could integrate the package manager with a test runner and allow packages to be uploaded with a collection of tests that define the public contract. Those tests would be published, so users can know what they can expect not to break, and any package update needs to either pass all those tests or be given a major version bump and an updated test suite.
|
# ? Jun 25, 2019 12:02 |
|
to show how goofy this is -- in TypeScript, adding a private method to a class is a potential API breakage, because if someone extends the class and adds a public method with the same name, the parent class could erroneously call the subclass public method instead of the private method it wanted. this is because JS obviously doesn't have true private/public (cough yet cough), and TypeScript doesn't name mangle private fields. in practice, nobody actually bumps major version if they add a new private method to an exported class, because this breakage is extremely rare in practice to the point that it has never happened afaik. API breakage is more of a social construct than something that can truly be verified.
|
# ? Jun 25, 2019 12:08 |
|
The Elm-style automated API breakage detection I was endorsing definitely requires a proper static type system. Just consider monkey patching, how would the package server even detect that somewhere in your init code you're running ButtClient.prototype.getFart = function() { return poop; }?
|
# ? Jun 25, 2019 13:19 |
|
I don't think the verification is up to the package management side, it just manages the packaging. It's up to one's own deployment bit to check what's being deployed, for instance with tests that assert getFart() === fart. I can install all sorts of stuff from npm, test it thoroughly once and then just leave it on the web server forever. It will not be affected by malicious package manipulation if I don't rebuild and redeploy. If an automated environment went through all the updates and did static analysis on them, it could at least detect some new request or some other suspicious pattern, halt the update and warn you. At least it gives a modicum of protection, which would also help against left-pad type situations. It could even throw a full all-hands code red if is-odd gets imported.
|
# ? Jun 25, 2019 13:39 |
Run your integration test suite from the previous version against the new version.
|
|
# ? Jun 25, 2019 16:02 |
|
SupSuper posted:We might as well just get rid of "0.x" and "1.0" because nothing can truly be considered "finished" anymore and half the packages the web depends on are beta. Have you considered TenVer?
|
# ? Jun 25, 2019 19:12 |
|
Remember the old saw, "Never buy Anything 1.0 from Microsoft?" Release numbers stopped being meaningful as soon as companies realized that they had an emotional impact. I've worked for so many companies where what should have been release 5.0 was actually 4.5, because the customers would balk at a major upgrade. Never mind that the amount of work to port was still there. e: I am also maddened by Apple's refusal to name its hardware. I'm typing this on a Macbook Pro Retina "Early 2015". No. Really. Those are the official release names of hardware configurations.
|
# ? Jun 25, 2019 20:25 |
|
Arsenic Lupin posted:Remember the old saw, "Never buy Anything 1.0 from Microsoft?" Release numbers stopped being meaningful as soon as companies realized that they had an emotional impact. I've worked for so many companies where what should have been release 5.0 was actually 4.5, because the customers would balk at a major upgrade. Never mind that the amount of work to port was still there. MacBook Pro Retina "Early 2015" is just bonkers. They should go with something more sensible like Ubuntu 15.04.
|
# ? Jun 25, 2019 20:35 |
|
Arsenic Lupin posted:Remember the old saw, "Never buy Anything 1.0 from Microsoft?" Release numbers stopped being meaningful as soon as companies realized that they had an emotional impact. so ... they were never meaningful, then? like oracle called their first release version 2 for this reason, in the 1970s remember when firefox tried to abolish version numbers altogether, so you'd have literally no way to refer to a specific release, just "current" and "out-of-date"? good times
|
# ? Jun 25, 2019 20:36 |
|
Hey at least it's better than when Apple decided "The New iPad" was a great naming idea. And naturally, even though "The new iPad" was the first normal iPad to have a "Retina Display", "iPad with Retina display" was actually the model after "The new iPad". Because I guess they hired a trickster god of folklore to decide their naming scheme for a while.
|
# ? Jun 25, 2019 20:39 |
|
fishmech posted:Hey at least it's better than when Apple decided "The New iPad" was a great naming idea. And naturally, even though "The new iPad" was the first normal iPad to have a "Retina Display", "iPad with Retina display" was actually the model after "The new iPad". i mean there's a long history of doing that kind of poo poo at least. like the new college in oxford, which has been referred to as "new" since *checks wikipedia* 1386
|
# ? Jun 25, 2019 20:43 |
|
Shout out to Sony for doing the sane thing with Playstation names. I'm sure someone will quote this and make me aware of an obscure PS model that was named nonsensically.
|
# ? Jun 25, 2019 20:46 |
|
Soricidus posted:so ... they were never meaningful, then? like oracle called their first release version 2 for this reason, in the 1970s They were meaningful for poo poo like BSD, where there was no marketing team involved. And Microsoft did release a lot of 1.0 products, so named, in the early 80s IIRC.
|
# ? Jun 25, 2019 20:59 |
|
Arsenic Lupin posted:I've worked for so many companies where what should have been release 5.0 was actually 4.5, because the customers would balk at a major upgrade. At a previous job, we had a code generation tool that would put its version into all the code it generated, so you could see what needed to be updated. The rule was that, if you could regenerate all of the generated code and not have to refactor anything, it was a minor version and you should mark it as such and regenerate all the code. If you could not regenerate everything without build errors, you should mark the change as a major version update and could refrain from regenerating everything, instead only regenerating stuff they touched. Somebody marked a minor change as a major version bump, possibly so they wouldn't have to regenerate everything, and I was very conflicted over whether to reject the pull request and make them fix the version number and regenerate everything. I figured that wasn't a battle worth fighting and just added "(should have been version 5.2)" to the version history in the company wiki. Then I added several paragraphs of additional documentation to the Javadocs for the version number in the code and I'm sure nobody ever read it.
|
# ? Jun 25, 2019 21:07 |
|
Eggnogium posted:Shout out to Sony for doing the sane thing with Playstation names. Yeah the hardware names are sensible, but the upda This post is receiving important updates, please do not scroll away. █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1% 0.195GB / 19.34GB (34 hours left)
|
# ? Jun 25, 2019 21:11 |
|
the only good version numbering scheme is the tex one
|
# ? Jun 25, 2019 21:28 |
|
Eggnogium posted:Shout out to Sony for doing the sane thing with Playstation names. PS Vita
|
# ? Jun 25, 2019 21:44 |
|
We have a number of ticket queues at work, and at one point we had "TechSupport Queue" and "#TechSupport Queue." Which is which? Well, one takes all the daytime cases and phone calls for one time zone, and the other takes all the cases for a different time zone that come in thru the ticketing system. But which is which? And what time zones are we referring to? What if someone makes a ticket and then calls in to follow up? Well, just put it in the appropriate queue. Which is...wait, gently caress.
|
# ? Jun 25, 2019 21:58 |
|
Jazerus posted:there is versioning but the way npm handles it on the package consumer side is extremely bad I bring this up every time we talk about it. Or you pin to a version and then the maintainers decide to swap what the versions mean. Years ago at this point we had a project no longer build able because it relied on “3.2.6” of uglyfy.js and for a year all was good. Then the developers wrote uglyfy2. And some time later they decided that if you used uglyfy you really meant uglyfy2 so they overwrote the mom package. Only uglfy2 was on version “2..1.1”. So the dependency couldn’t be satisfied and the builds failed for all eternity.
|
# ? Jun 26, 2019 05:13 |
|
Reminder that Microsoft called the Xbox One that, supposedly because they were hoping/expecting the crowd would start referring to it as "the One". They certainly didn't expect "Xbone".
|
# ? Jun 26, 2019 07:06 |
|
Dirt Road Junglist posted:We have a number of ticket queues at work, and at one point we had "TechSupport Queue" and "#TechSupport Queue." Once upon a time we had a queue called "no contract", which was exactly what it said on the tin. Then we renamed it to "on demand" because things that were outside contracts were being charged as no contract and it was confusing. Recently we've decided that "on demand" wasn't the right queue for someone with a contract, so now it's "out of scope" and "on demand", where "on demand" is anyone without a contract and "out of scope" is a contracted customer looking to have something done on demand. Queue names are bullshit. Embrace it.
|
# ? Jun 26, 2019 08:20 |
|
Soricidus posted:i mean there's a long history of doing that kind of poo poo at least. like the new college in oxford, which has been referred to as "new" since *checks wikipedia* 1386 I think you mean 'The College of St Mary of Winchester in Oxford' my good man. Or alternatively New College, nobody would talk about 'the new college' that sounds weird. (It's a bit different when other random people do it informally rather than as an actual corporate strategy, tbf) Edit: 'Remember the old saw, "Never buy Anything 1.0 from Microsoft?" - the first release of Windows NT was, of course, version 3.1.
|
# ? Jun 26, 2019 12:14 |
|
feedmegin posted:Edit: 'Remember the old saw, "Never buy Anything 1.0 from Microsoft?" - the first release of Windows NT was, of course, version 3.1.
|
# ? Jun 26, 2019 15:52 |
|
... Google wants to rewrite libc.This couldn't possibly be a bad idea posted:> If there is a specification, we should follow it. The scope that we
|
# ? Jun 26, 2019 16:16 |
|
Arsenic Lupin posted:... Google wants to rewrite libc. No.
|
# ? Jun 26, 2019 16:25 |
|
iospace posted:No. " some parts which cannot be safely used in modern coding practice." Trust the Google. Just because your existing code breaks into a thousand chiming iridescent pieces when they delete [strcpy / whatever] it will all be worth it in the end.
|
# ? Jun 26, 2019 16:29 |
|
Arsenic Lupin posted:" some parts which cannot be safely used in modern coding practice." I don't trust Google as far as I can throw them, for many, many things.
|
# ? Jun 26, 2019 16:35 |
|
I like the idea that they seem interested in writing a safe, statically linked libc. That has positive implications for embedded applications. That's about all I like from this project proposal, though.
|
# ? Jun 26, 2019 16:38 |
|
Kazinsal posted:I like the idea that they seem interested in writing a safe, statically linked libc. That has positive implications for embedded applications. Yeah, that'll be nice for embedded folks like myself (and UEFI folks as well), but uh, yeah...
|
# ? Jun 26, 2019 16:44 |
|
What would be the difference between what they describe and musl?
|
# ? Jun 26, 2019 17:12 |
|
musl isn't suitable because hrrm hmmr hrmrm but don't worry guys it'll be an open development process.
|
# ? Jun 26, 2019 17:45 |
|
they could call it glibc! oohh wai
|
# ? Jun 26, 2019 17:47 |
|
dougdrums posted:What would be the difference between what they describe and musl? They already forked musl. New worlds to conquer!
|
# ? Jun 26, 2019 17:57 |
|
the linked email involves someone complaining that their fork of musl involves some baffling and nonsensical changes that were made without really understanding why the original was the way it is so I'm sure this version will work just great
|
# ? Jun 26, 2019 18:23 |
|
Scaramouche posted:they could call it glibc! Don't worry, if libcrurl is anything to go on I'm sure they'll do something totally clear and distinct like gllibc.
|
# ? Jun 26, 2019 18:27 |
|
They talk about a growing range of needs they can't get from existing libcs, but don't say anything at all about what those needs are. I wonder why they want to reinvent this particular wheel.
|
# ? Jun 26, 2019 19:05 |
|
Also it seems pretty lovely to be like “hmm we want to write our own libc for specifically x86-64 linux, maybe we can toss the work of making it cross platform and cross abi to those hogs on llvm”
|
# ? Jun 26, 2019 21:03 |
|
Arsenic Lupin posted:" some parts which cannot be safely used in modern coding practice." If you are using strcpy then your code deserves to break.
|
# ? Jun 26, 2019 21:07 |
|
|
# ? Jun 8, 2024 09:27 |
|
Arsenic Lupin posted:" some parts which cannot be safely used in modern coding practice." Preventing binaries that use str(n)cpy from running sounds like a feature.
|
# ? Jun 26, 2019 21:22 |