hunger

joined 2 years ago
[–] hunger@programming.dev 2 points 1 year ago* (last edited 1 year ago) (2 children)

No, I would prefer a world where not everything is concentrated on github, but that is the world we have to work with:-)

But how does this address any of the problems you brought up?

Do you think a project will be more discoverable when you say: "Clone foo/bar from github" or when you say "install this strange crypto-BS, then clone rad:xyhdhsjsjshhhfuejthhh just like you normally would"?

Apart from discoverability you get a known workflow for contributors, a CI and a bug tracker. Coincidently those make it hard for projects to switch away from github... how does this address any of that? "Use this workflow, which is even wierder than any of the other github alternatives!" and "just set up a server yourself"?

Sorry, this is just yet another crypto-bro solution in search of a problem. Technically interesting, I'm give you that, but useless.

[–] hunger@programming.dev 13 points 1 year ago (12 children)

Serious question: What is the point?

Just push into half a dozen mirrors and you are pretty censorship resident without the crypto voodoo put on top of git.

Github has one huge value: Discoverability of a project. This is even worse than hiding your project in one of the smaller forges... nobody can remember the mess of letters you need for this.

[–] hunger@programming.dev 4 points 1 year ago (1 children)

So you see C programmers as sabotaging public infrastructure?

[–] hunger@programming.dev 4 points 1 year ago (2 children)

Yeap, -O3 is mostly voodoo. Berger has some measurements.

Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)

[–] hunger@programming.dev 15 points 1 year ago

Ansible must examine the state of a system, detect that it is not in the desired state and then modify the current state to get it to the desired state. That is inheritently more complex than building a immutable system that is in the desired state by construction and can not get out of the desired state.

It's fine as ,one as you use other people's rules for ansible and just configure those, but it gets tricky fast when you start to write your own. Reliably discovering the state of a running system is surprisingly tricky.

[–] hunger@programming.dev 3 points 1 year ago* (last edited 1 year ago) (4 children)

That's not utf8 either...

[–] hunger@programming.dev 4 points 1 year ago

Oh, come on... all C++ devs know C well enough. Nobody assumes C is bad because it is more insane than C++.

C is just awfully repetitive as you have to spell out all the cleanup code all time -- and you are likely to have a security issue when you forget it just once.

[–] hunger@programming.dev 2 points 2 years ago

The quote above covered exactly what you just said: "yet were also more likely to rate their insecure answers as secure compared to those in our control group" at work :-)

[–] hunger@programming.dev 7 points 2 years ago* (last edited 2 years ago)

That interface is let any random app take screenshots of anything running on the same server without any way for the user to know it happens.

I am so glad that interface is gone, especially when running proprietary apps.

[–] hunger@programming.dev 4 points 2 years ago

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

[–] hunger@programming.dev 9 points 2 years ago (2 children)

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That's because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

[–] hunger@programming.dev 1 points 2 years ago

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that's due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.

view more: ‹ prev next ›