Yes, obviously there are more ways to hide malicious code.
As for the git commit ID, I didn’t see you using it even when it was available though? But perhaps that could be a weakness, if the commit ID used does not match the tag in the repo, that would be a red flag too. That could be worth checking.
Due to the recent xz trouble I presume? Good idea, I was thinking about this on an ecosystem wise scale (e.g. all of crates.io or all of a Linux distro) which is a much harder problem to solve.
Not sure if the tag logic is needed though. I thought cargo embedded the commit ID in the published package?
Also I’m amazed that the name cargo-goggles was available.
Sure, but my point was that such a C ABI is a pain. There are some crates that help:
But without those and just plain bindgen it is a pain to transfer any types that can’t easily just be repr(C), and there are quite a few such types. Enums with data for example. Or anything using the built in collections (HashMap, etc) or any other complex type you don’t have direct control over yourself.
So my point still stands. FFI with just bindgen/cbindgen is a pain, and lack of stable ABI means you need to use FFI between rust and rust (when loading dynamically).
In fact FFI is a pain in most languages (apart from C itself where it is business as usual… oh wait that is the same as pain, never mind) since you are limited to the lowest common denominator for types except in a few specific cases.
Yes, rust is that much of a pain in this case, since you can only safely pass plain C compatible types across the plugin boundary.
One reason is that rust doesn’t have stable layouts of structs and enums, the compiler is free to optimise the to avoid padding by reordering, decide which parts to use as niches for Options etc. And yes, that changes every now and then as the devs come up with new optimisations. I think it changes most recently last summer.
So there is a couple of options for plugins in Rust (and I haven’t tried any of them, yet):
I don’t know if any of these suit your needs, but at least you now have some things to investigate further.
Swedish layout. Not ideal for coding (too many things like curly and square brackets etc are under altgr. And tilde and backtick are on dead keys.
But switching back and forth as soon as you need to write Swedish (for the letters åäö) is just too much work. And yes, in the Swedish alphabet they are separate letters, not aao with diacretics.
Interesting repo and seems useful as a teaching aid, the algorithms seem to be written with a focus on readability.
However, if you actually need to do any of these operations in production I would recommend finding an optimised and well tested implementation instead. This is especially important for the cryptographical algorithms! But even for something like counting set bits, modern x86-64 CPUs even have a built in instructions for that (POPCNT).
LGPL specifically does as far as I understand have some issues when used in rust. In particular the border for the copyleft is dynamic linking. That doesn’t work well with rust. I would instead consider MPL where the copyleft border is on a source file level.
That said, I’m not a lawyer!
Saying “it’s a graph of commits” makes no sense to a layperson.
Sure, but git is aimed at programmers. Who should have learned graph theory in university. It was past of the very first course I had as an undergraduate many years ago.
Git is definitely hard though for almost all the reasons in the article, perhaps other reasons too. But not understanding what a DAG is shouldn’t be one of them, for the intended target audience.
I really don’t see what niche it is trying to fill that isn’t already occupied.
Rust is as successful as it is because it found a previously unoccupied niche: safe systems programming without garbage collector and with high level abstractions that (mostly) optimise away.
I don’t think “better C” is a big enough niche to be of interest to enough people for it to gain a critical mass. I certainly have very little interest in it myself.
Doesn’t really help: what if you typo the namespace instead? Same exact issue. Namespaces are useful for other things though, but not security.
There are existing approaches: GNU gettext and Mozilla fluent comes to mind. I would try to use one of those. I understand that Mozilla Fluent has good support for the Web (unsurprisingly).
Your idea will work with minor changes (if comments are supported in your file format). At work our tooling create entries like 123="English text" // UNTRANSLATED. Obviously not quite the same format, but it should be adaptable to any format that supports comments.
Be sure to treat state and configuration separately. It doesn’t matter on Windows as far as I know (they go in the same location), but on Linux those are supposed to go in different places.
Many programs get this wrong, and it is quite annoying as I track my config files in git. I don’t want a diff just because the list of recently opened files changed! Or even worse: the program stores the last window size and position in the config file… (looking at you KDE!)
Here are some libraries I found to help with this in a cross platform way:
I haven’t tried either, haven’t written such a program yet.
As for how to store data, there are indeed many options, depending on your needs:
Without knowing more it is hard to give specific advise.
Hm, that is a fair point. Perhaps it would make sense to produce a table of checks: indicate which checks each dependency fails/passes, and then colour code them with severity.
Some experimentation on real world code is probably needed. I plan to try this tool on my own projects soon (after I manually verified that your crate match your git code (hah! Bootstrap problem), I already reviewed your code on github and it seemed to do what it claims).