The solution is to not use Http based validation of the cert, but use dns based validation. Possibly combined with a wildcard cert for your whole domain. This is what I do for internal services on my LAN, along with split DNS so that the internal services aren’t even listed in public DNS.

What is that log analysis tool you are using in the picture? Looks pretty neat.

It is common custom to indicate quotes, with either “quotes” or for a longer quote a

block quote

The latter can be done by prefixing the line with a > here on lemmy (uses the common markdown syntax).

Doing either of this help avoid ambiguity.

Agreed, I run arch on my desktop and laptop, because it is more stable (in the sense of fewer bugs, things like suspend/resume works reliably for example) than any other distro I have used.

But on my VPS and my Pi I run Debian because it is more stable (in the sense of fewer upgrades that could break things). I can enable unattended upgrades there, which I would never do on my Arch system (though it is incredibly rare for those to break).

Also: if someone said they were a (self proclaimed) “semi noob” I would not recommend Arch. I have used Linux since 2002, and as my main OS since 2006. (Furthermore I’m a software developer in C/C++/Rust.) While Arch is a great distro, don’t start with Arch.

That seems to be for dns resolving, not for ddns? Or am I missing something?

Most registrars also run DNS servers as part of the fee you pay for the domain. Usually they have an API. You can just use that to implement Dynamic DNS, there are even often tools for it. Do a search for your DNS registrar and dyndns.

Afraid.org is better than DuckDNS. (DuckDNS is not reliable and have been slow or down a lot.)

But it is still American.

Let’s Encrypt is meant yo be used with automated certificate renewal using the ACME protocol. There are many clients for this. Both standalone and built into e.g. Caddy, Traefik and other software that does SSL termination.

So this specific concern doesn’t really make sense. But that doesn’t mean I really see a use case for it either, since it usually makes more sense to access resources via a host name.

Unless they are in different cities they wouldn’t be safe from a fire, lightning strike, earth quake/flood/tsunami/typhon/hurricane/etc (remove whichever ones are not relevant to where you live).

That seems like a really big downside to me. The whole point of locking down your dependencies and using something like renovate is that you can know exactly what version was used of everything at any given point in time.

If you work in a team in software, being able to exactly reproduce any prior version is both very useful and consider basically required in modern development. NixOS can be used to that that to the entire system for a Linux distro (it is an interesting project but there are parts of it I dislike, I hope someone takes those ideas and make it better). Circling back to the original topic: I don’t see why deploying images should be any different.

I do want to give Komodo a try though, hadn’t heard about it. Need to check if it supports podman though.

I haven’t used Komodo, but would it commit to the updated docker files to git? Or just use the “latest” tag and follow that? In the latter case you can’t easily roll back, nor do you have a reproducible setup.

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

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:

• Rust-C++: cxx and autocxx
• Rust-Rust: stabby or abi_stable

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

• Wasm, supposedly https://extism.org/ makes this less painful.
• libloading + C ABI
• One of the two stable ABI crates (stabby or abi_stable) + libloading
• If you want to build them into your code base but not have to update a central list there is linkme and inventory.
• An embedded scripting language might also be a (very different) option. Something like mlua, rhai or rune.

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!