scp has the assumption that you have a login on the computers you're trying to share data from. wormhole allows for sharing with others without providing login access to the computer
Right. Also you may have to reconfigure some firewalls to use scp.
Typically, a firewall allows outbound connections without needing an explicit entry for the protocol, and in the case of magic wormhole, both sides are an outbound connection. So it passes right through.
If you've got security-minded folk managing that sort of thing for you, it's possible that magic wormhole will upset them for this reason. More for policy/compliance reasons than actual security ones.
Both problems can be worked around by having a third, general-purpose host where both source/destination hosts can scp to/from. Not quite as straightforward because you have to copy twice and do it from both sides, but has the benefit of not having to install bespoke software.
I think you could use an ssh tunnel between the intermediary and the destination such that the scp connection from the source makes it all the way through in one go, rather than leaving files on the intermediary. You'd be forwarding to the ssh port via ssh, so it would be a confusing bit of sshception.
If I tried to actually come up with the actual commands for this, I'm sure I'd burn a whole afternoon on fiddling with it.
Redhat (pre-RHEL) solved package signing around 1999 with RPM 2.0/3.0 by using PGP and later replacing it with GPG. Debian solved it around 2003 by also using GPG.
With truly reproducible builds, it's possible to introduce distributed caching of artifacts and selective probabilistic rebuilds from source to attest/verify integrity in a distributed manner.
1. There should be an easy-to-use API, CLI, library, and data (sqlite db or whatever) to query package metadata efficiently.
2. The mythological purity of rolling releases building against edge versions without dependency constraints or maintaining stable versioning causes problems in the real world(tm). There are many cases where past versions are needed. Example: ffmpeg is buggy as hell and has to be managed very carefully. Another example: binutils, gcc, mpfr, mpc, and toolchain friends have to be built together with compatible versions. Further example: don't compile anything with Clang/LLVM 14+ unless you want all of your code to break because some genius decided to break the world out of ideological perfectionism. macports, Homebrew, nix, and Arch are just some who are guilty of this sin.
Packages are signed in exactly the same way Debian packages are signed, ie the package files themselves are not signed but the index file that lists them is.
Is this because you have a time-locked transaction to move the funds from the P2MS to a P2PKH? How does that work when it's "re-keyed"? Wouldn't each re-key move to a new P2MS and have a transaction fee associated with it as well as have a second transaction for the HTLC transaction?
Bitcoins entire premise is around the movement of unspents. If you always use the same wallet for every transaction it is pretty easy to track who sent the money. If you instead are always sending your money to a newly derived wallet from your HD (Hierarchical Deterministic) root it does make it much more difficult to track what money was money being spent on something and what money is part of a persons total value
https://github.com/SAMA-Communications/sama-server/tree/main... https://github.com/SAMA-Communications/xmpp-adapter
Also I don't see anything about E2EE support