Single developer projects

How are we supposed to trust single developer security and privacy projects? There are so many out there. So I had a gemini lake chromebook. Wanted to wipe and install a good OS. The support wasn't there yet. Checked again. The support is now there. Yesss. A fully functional rugged mini laptop with a large battery for $20. There are two projects which allow linux to be installed on these devices, mister chrom box and breath. Both of these projects seem to be anonymous single developer projects. The breath developer has said that they are under 16. Seems extremely impressive. Should we be looking for more transparency from people writing firmware level hacks for our devices? Like, has anyone audited these scripts for security? I'm probably gonna use one of these methods to install a decent distro onto this device, and the project developers are most likely genuine, but it seems like malign actors would see an exploitable weakness there.

>>19386 Audit them yourself if you care about that. Or don't use them. You're not entitled to soykaf.

>>19387 We shouldn't question the bona fides of anonymous devopers who are solely responsible for widely used security and privacy projects? Git gud and build your own? gtfo globot

So I started looking into this. It's amazing how many security projects are controlled and administered by one person with the help of a protective community that will rage against basic questions about best practice. Do people really need it explained why this is a bad idea? Are there any examples of developers acknowledging the dangers and accepting oversight?

>>19397 >Are there any examples of developers acknowledging the dangers and accepting oversight? Literally every open source project.

>>19400 I should have been more specific. Are there any examples of longtime single dev projects, that many people rely on as part of their security and privacy stack, that have acknowledged the dangers and given up total control. Giving up their baby I guess. It's an honest question that I haven't seen addressed. Any time it's asked people get defensive, especially on project community forums.

>>19386 First, you can't trust anything you didn't entirely build. That applies to the entire hardware/software stack, and is just how it is. Second, single developer doesn't mean a single brain. Open source projects usually deal with issues raised and audits performed by the general public. That's a collective action problem: if you don't participate, don't expect a secure result. TL;DR: audit things yourself. If you see something, say something, and save the world.

OP here. It feels like people are deliberately not addressing the main point. A single developer in control of a project is a single point of failure for critical security infrastructure. Even the most basic bribery or coercion will be effective. "Git gud and audit it yourself" is not a reasonable response. The ideal solution is for some kind of group of known, public, proven trusted devs to share control and auditing with the project creator. Batman gave control of his panopticon to morgan freeman ffs. Everyone knows what best practice is, why do we argue against implementing it? The ideal situation for the projects in the OP would be for the creators to cede control to something like a committee of open source coreboot developers, like scientists open sourcing their pharma discoveries for the good of humanity instead of commercializing them. Why are we so against even aiming for this outcome?

>>19420 committees aren't good. committees have tendancies to get caught up in internal politics, charismatic leadership, etc etc, they add a lot of complexity to project management and may scare away good autists who only care about good code, in favour of people people with other agendas. The best system is projects managed by benevolent autists, most likely. People who care enough about the project that they are naturally very dedicated to its honesty and merit, much more than they care about whatever bribes might get them. Community should take care of these people so that they aren't easily threatened by blackmail or put in vulnerable positions out of desperation.

>>19420 So what projects are you looking to forcefully remove from the control of it's creator? It's for the children right?

also: beauty of free software, if you have a committee it can just make a fork and have both systems in parallel.

>>19421 >committees aren't good. committees have tendancies to get caught up in internal politics, charismatic leadership, etc etc, they add a lot of complexity to project management and may scare away good autists who only care about good code, in favour of people people with other agendas. Holy fuarrrk. What a post. Committees aren't "good"? What do you think a board of directors is? What do you think happens in a national senate? Benevolent autists? Are they like benevolent dictators? People have some very strange ideas. >>19422 Is that supposed to be a gotcha question or something? Any project where the public good outweighs the right of the creator to personally profit from their creation should be controlled by the public. It's a well understood concept the world over. An example, if you need it: If a scientist discovers a cure for cancer, the right of the citizens of the world to have that discovery open-sourced outweighs the right of the creator to keep control of the discovery. These are basic, well understood, uncontentious concepts. When it comes to software that we all rely on for our privacy and security they shouldn't be questioned.

>>19427 >What do you think a board of directors is? What do you think happens in a national senate? in a great many cases, both are giant steaming piles of horse manure and not in a good way. Benevolent autist, benevolent dictator, sure. The Autist, especially on single dev projects though, isn't doing too much dictation. He's just working on his hobby, you don't have to be a part of it. >When it comes to software that we all rely on for our privacy and security they shouldn't be questioned. >We should must extract secrets from certain people for the greater good. It is not the right of these people to keep secrets. lain lain lain lain lain what the hell are you thinking. Either privacy matters or it doesnt, please commit one way or the other I don't really care which.

No one has a right to another person or their property. This smells like the start of another round of coc suckers.

>>19420 >muh capeshit Nevermind, you're just a kid. Grow up, git gud, lurk more before posting cringe. >The ideal solution is for some kind of group of known, public, proven trusted devs to share control and auditing with the project creator. You're proposing, in other words, an oligarchy for the free software world. These trusted devs would come from respected and trusted corporations, I presume? Or should they get appointed by our rotting universities? How would they make money? Government grants? Can't see that going wrong. The actual solution is for software "engineers" to either accept liability for damages or explicitly state that their programs are not trustworthy and unfit for use in critical infrastructure. That's how actual engineers - eg civil engineers - work. Watch this if you need convincing: https://youtube.com/watch?v=nT-TGvYOBpI

Single developer = single point of failure = bad super simple stuff guys.

Fork>Make your fork better>become the preferred version>invite oversight committee to guard against single Dev 'issues'>Profit.

You need better & audited hardware before you can even start caring about software / firmware security... I mean, you can care if you want, I won't stop you, but holy soykaf man, Ken Thompson called, he wants his 1984 ACM acceptance speech back... Ken warns of the compiler hack applying to microcode. Damn chips have decompilers and code rewriters and god knows what else... management engines? Why does anyone trust a company that jokes about your security naming themselves after gov info gathering "INTEL"? Computer Security is literally a joke: CumPooTurd SuckYourTitty. I have been working on a hardware chipset design that is actually far more secure. Security starts at the hardware level... imagine trying to add process separation to MSDOS - it really took hardware features to allow that to be implemented (apart from running everthing in a VM). My architecture does things that other chips refuse to do (as if they don't want you to have security) - for instance, the stack is guarded. INTEL is getting there with SHADOW STACK (tm), but then just ditch the other "normal" stack, guys... And provide dedicated opcodes that are the only way you can load/store from this hidden stack... and formalize function stack frames (but don't do it like ARM or intel's chips do). If you secure that part you can lock down the code paths to only that which was programmatically defined. In my system, a LEAVE instruction always returns to the call site, no return oriented programming is possible, the stack is secured in memory that user space code can not normally touch except through sanitized opcodes. Small mistakes in software will almost never result in compromise of the program because the hardware is more secure. More secure hardware is possible. I have given up on the rest of the world's security, but it's possible to build a chipset of your own and load it on an FPGA, or even just get an ASIC production of your VM functions. I'll publish my system someday, but I'm not interested in "help" from any sort of community - let's face it, other humans are uniformly all fools (esp. when it comes to MY project). Let's take a look at one of the idiotic designs that all you monkeys repeat for no fuarrrking reason. This will prove you're all fools, for not realizing it yourself. How do function stack frames work? Well, the monkey would put forth that before a function call, some memory is allocated for the function stack frame depending on the number of local variables needed. Then the current Instruction Pointer is written to the stack somehow, and the function's code entry point is jumped into. The stack grows down. Shouldn't it grow UP? Can't start a stack from the top - go ahead and try with blocks, it don't work -- form not matching description is a prime source of misunderstanding and insecurity - The beginning of wisdom is to call things by their correct names, get it? Sure, sure, it is actually functionally equivalent to growing down - but only if you do all the stack things down too. Look at the stack frame. Vars are stored relative to the top of stack pointer, and typically accessed with negative constant numbers. What if you move the top of stack to allocate more stack? You can't really do that easily at any point in a general purpose way because of the halting problem. Even if you copy the stack to a new location and move the (top of) stack (down) to encompass that interval, one could have pointers to those old locations floating about in heap memory or existent registers. The compiler can invalidate all the registers, but it can not solve the halting problem and guaranteed the coder it can track down all old reference to the prior stack locations. What if another function wrote the pointer values to swap space for later, or sent the pointers half-way around the world and back? Now, imagine this: During a function you just use however as much stack space as you fuarrrking want - it's all yours. Hello free dynamism. There is no "frame" until you actually call another function. At invocation of another fn() the current stack amount in use is marked along with return IP. Parameters are placed at the end of the stack, and the VISIT (call) instruction takes a parameter count from constant or register. The invoker's stack frame gives those words to the start of the next function's stack (even better if compiler arranges for the values to be there due to the course of execution). The newly invoked function can see the parameters, they're on its stack -- A function can never access memory lower than the current top of stack (in my system stack grows up, and uses only unsigned values relative to the stack pointer to access stack slots). So, hardware GARAUNTEES that a function can trust any value it had on the stack before invoking another function, will ABSOLUTELY not be tampered with by any successive function invocation graph. Goodbye Return Oriented Programming - not possible in my system. Goodbye stack smashing - stack is secure and no shadow stack is needed, derp. Hello dynamically resizable stack. The invoked function can read a parameter value then allocate Now, there's nothing (but cruft) stopping C (et. al.) from adopting this dynamic frame strategy today - however the hardware will not provide any strong guarantee that stack is not tampered with. In my C-ish proof of concept / chip smoke-testing lang, I can do this: int myArray[5] = invokeFn( 5, otherArray ); ... int[] invokeFn( num, srcArray ) { int stackArray[ num ] = { 0 }; // fast stack alloc, no malloc() needed. ... return stackArray[0..(num-1)]; // a range of values is returned to populate myArray above (perhaps on the stack). } If you want a dynamic array size in C you have to use malloc, which incurs plenty of overhead... For most purposes it's fine to just a stack allocation, but resizing C's ABSOLUTELY MORONIC stack strategy needlessly encounters the halting problem. Why do chipset makers not tell C compiler devs to fuarrrk off and give them a better way? Why are other lang designers not giving speeches in Uni about how pre-allocated stack frame is just fuarrrking wrong (use as much stack as you want at all times, and only lock the stack to a fixed size before you invoke another fn, FFS). The problem is no one wants to hear that their emperor wears no clothes. Because this is a joke about Amun-Ra: God of hidden powers, invisibility, and wind, who granted all great kings/emperors their divine right to rule via an invisible mantle of protection. Ra Deus (radios) are the all-seeing-eyes, or IIs, it has looks that can kill... look up "microwave burn" in relation to telecoms servicemen. So, having the invisible cloak of protection of Amun-Ra, the emperor needs no other armor(protection) / amoire(clothes) / amore(love)... See? The academic will enjoy having their nose rubbed in the fact that every time they repeated the ignorant child's shout "the emperor wears no clothes!" they were being made a fool of... The book is a self referential joke, common among the (allegedly) "enlightened" occult - it's just a re-telling of Plato's Cave, which is his anus... Archaic "men" = "lumps". A turd is turtling, it sees a bit of light, butt goes back inside attempting to free the other men chained up in the rectum [hnnnnngh!], it fails to do so, butt is set free and has seen the light of day for itself. This "cave" is also the labyrinth of Theseus[they see us] - who fights the men-of-tar, and gets lost as a sex toy with no string up your arse [in the intestine] when someone sees you with a bit of wood up the arse "They see us!" [clentch, whoops, God of invisibility Rears its ugly head again - it's A raw MOON instead of Amun-Ra] The proctologist says you shoulda put a string on it if you liked it so much... So Theseus is gifted a ball of yarn to help him find his way out of the "Labyrinth". Now that you know the mystery of Play-Dough's "Cave" [of wonders], and that most occult traditions invoke potty humor at some young layer of understanding, you simply can not discuss it with a university philosophy professor. Such is the nature of Plato's Cave... The same with Emperor's New Clothes, or Theses... Fools, the lot of ye be, Arrrrgh. No one wants to hear about a more secure way to operate hardware - they actually imagine it would have already been discovered long ago if it were possible. Newsflash: A million monkeys typing on typewriters will not actually ever yield any work of Shake-Spear (jerk-off reference)... They are biased towards striking certain combination of keys far more than others, and may actually only alternate left vs right half of the keyboard. But the scientist and statistician, have no ears or eyes when you try to tell them that radio beam weapons can skew all their experiments, Amen. pic: Thoth (thinking) as a monkey makes hands like the electrode in the bulb, and above his head is the solar disc... saying, "Think... it's like the sun". So this shrug becomes the "meh, i dunno" gesture and a light-bulb above the head becomes the sign for idea (thoth)... and such prior art is never considered in suppressive patent system filings. No one ever tested the patent system for usefulness, "scientists" just have a blind faith that it's good for innovation, somehow... TL;DR: OP, please, you don't want security, you don't even know what that is yet... You don't even know what surveillance is. You have no eyes, nor ears... well then: FriEnds, Roh-Men, Cunt-Tree-Men, Lend me your Rears!

>>19477 you just made C impossible to implement. consider this simple snippet of code: void increment(int* x) { *x += 1; } int main() { int x; increment(&x); return 0; } the `increment` cannot access the pointer to `x` since that's in lower memory than its stack frame > During a function you just use however as much stack space as you fuarrrking want you can already do this. see "variable-length arrays" in C. also the way you're proposing it should work is how it already does, except instead of the frame size the stack pointer is pushed. so idk what you're complaining about --- seems to me your changes would force the system to be a lot slower since you would be forcing A) A ton more heap allocations B) A ton more useless copies C) there would need to be runtime checks to see whether you can access a pointer through the normal load-store opcodes or you need to use the "special stack-dedicated opcodes" also you're completely breaking backward compatibility with literally all previously made software. that's never going to work

>>19476 Git Gud and make your own is not a legitimate position on this simple concept. People specialize in different fields. In every other field people recognize the frailties and failings of the single individual. Therefore we have oversight committees or whatever. A journalist should not have to rely on security software from a single developer, nor should they be expected to fork the project and make their own. It is not reasonable. Super simple stuff folks. >>19477 >>19479 Seems like people just want to make super simple concepts ridiculously complicated and obscure. Thanks guys.

What projects make you most concerned? A little context might help your argument.

>>19489 >A journalist should not have to rely on security software from a single developer, nor should they be expected to fork the project and make their own. It is not reasonable. a journalist who can't manage his own opseck and gets bitten by it deserves whatever pain Fate elects to bestow upon him. Actually he probably deserves worse, but lets not get into that. A lot of opsec and security in general amounts to common sense and a builtup system of trust. Untrustworthy entities can generally only directly betray that trust a few times before they're irrevocably damage. No software can fix a dumb person, and a careful person can often manage the risk placed on marginally trustworthy tools. If Journalists need their own fancy journalist software you'd think that some big journocorp could try and put together a project to do it. NYT, AP, these places have big programmer staffs. If there's free software that exists and suits their needs, its not their place to assert further demands upon its creators. That's like a beggar demanding uncreased bills. Maybe he has his reasons, but fuarrrk them, not his place to make demands.

>>19546 A surgeon is not expected to manage the code on the electronics they use. It's not a reasonable expectation. The surgeon can expect an extreme level of reliability and security in the electronics they use during surgery. That is a reasonable expectation. This requires extreme oversight of the code in those electronics. The right of billions of people around the world to expect the same level of reliability and security from their electronics is just as important. To protect free speech we must be certain that our private correspondence is private. I thought these were reasonably straightforward concepts to be honest.

>>19550 Its a straightforward concept, and I understand what you're saying. The thing is, I disagree entierly. I'm not even sure I think surgeons should not be responsible for their own software if they choose to use it (hey, they can hire someone to handly the tech stuff either directly or by proxy, and the ones who do it bad go out of buisness), letalone have orgs that take over free projects to advance the freedom of journalists. This strikes me as evil, debatably against the freespeech you're claiming to be supporting, and is basically theft, which I tend to oppose. On top of that, I'm not sure if its likely to even make anything better for these journalists than it currently is, but that's another matter to the question of whether its ethical--and its not ethical.