@hunger@programming.dev avatar

hunger

@hunger@programming.dev

A Slint fanboy from Berlin.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

hunger,
@hunger@programming.dev avatar

Rustfmt is not very configurable. That is a wonderful thing: People don’t waste time on discussing different formatting options and every bit of rust code looks pretty identical.

hunger,
@hunger@programming.dev avatar

Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.

hunger,
@hunger@programming.dev avatar

When I last checked (and that is a long time ago!) it ran everywhere, but did only sandbox the application on ubuntu – while the website claimed cross distribution and secure.

That burned all the trust I had into snaps, I have not looked at them again. Flatpaks work great for me, there is no need to switch to a wannabe walled garden which may or may not work as advertised.

hunger,
@hunger@programming.dev avatar

“I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,”

My impression is that they are very aware of the state of C++ and the efforts to provide strong safety guarantees. That’s why they keep raising the pressure.

hunger, (edited )
@hunger@programming.dev avatar

That depends on how you decide which bucket something gets thrown into.

The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.

These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.

hunger,
@hunger@programming.dev avatar

That depends a lot on how you define “correct C”.

It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.

The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.

hunger,
@hunger@programming.dev avatar

Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.

I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.

Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.

hunger,
@hunger@programming.dev avatar

There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the “right” direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)

All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.

hunger,
@hunger@programming.dev avatar

GPL effects “derived works”. So if your code is derived from proprietary code, you can not use GPL, as you would need to re-license the proprietary code and you can’t do that (assuming you do not hold the copyright for the proprietary code). LGPL and permissive licenses are probably fine though.

Now what exactly is a “derived work”? That is unfortunate up to interpretation and different organizations draw the line in slightly different places. We’d need people to go to court to get that line nailed down more firmly.

andrew, to opensource
@andrew@andrew.masto.host avatar

Radicle: Open-Source, Peer-to-Peer, GitHub Alternative
https://radicle.xyz/
@opensource

hunger,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

No, I would stringing 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, (edited )
@hunger@programming.dev avatar

Then how do you not see the point of a distributed sourceforge?

But this is no forge, it is just a git repo.

Again, have you even opened the webpage?

Yeap, I even put a repo into it. That’s why I am so certain that it is useless.

Hosting a git repo is not a problem. Having an discoverable forge is. And this does not help with that in any way.

So github is not a problem?

Something can not be a solution independent of whether or not something else is another problem or not.

And regarding crypto, show me where in the code it forces you to use crypto. Show me the rad command that inhibits you from doing a normal git operation by bringing up crypto.

There is lots of needless crypto(graphy) going on all over the place. It is entirely useless for code hosting in a git repo.

hunger,
@hunger@programming.dev avatar

So you see C programmers as sabotaging public infrastructure?

is Wine with -O3 and -march=native a placebo?

For nerd purposes I’ve been trying to custom compile Wine to see if i can squeeze some performance out of it, i pulled out the -g flag and put in its place -O3 with march native. i don’t know how to benchmark properly to see if there at least a marginal gain, so idk if it is a placebo or not. tried to search for articles in...

hunger,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

That’s not utf8 either…

hunger,
@hunger@programming.dev avatar

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 :-)

Is it actually dangerous to run Firefox as root?

I have a few Linux servers at home that I regularly remote into in order to manage, usually logged into KDE Plasma as root. Usually they just have several command line windows and a file manager open (I personally just find it more convenient to use the command line from a remote desktop instead of directly SSH-ing into the...

hunger,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

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,
@hunger@programming.dev avatar

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It’s all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs – something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

hunger,
@hunger@programming.dev avatar

You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

So I seriously doubt you loose out when using AGPL or GPL.

hunger,
@hunger@programming.dev avatar

Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

hunger,
@hunger@programming.dev avatar

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • Leos
  • mdbf
  • magazineikmin
  • thenastyranch
  • hgfsjryuu7
  • InstantRegret
  • ngwrru68w68
  • Youngstown
  • slotface
  • vwfavf
  • rosin
  • PowerRangers
  • kavyap
  • DreamBathrooms
  • anitta
  • cisconetworking
  • everett
  • cubers
  • Durango
  • ethstaker
  • GTA5RPClips
  • khanakhh
  • osvaldo12
  • modclub
  • normalnudes
  • tester
  • tacticalgear
  • provamag3
  • All magazines
    •