murse's repository is going to be moving to the ~webb user on SourceHut. 
You can find new links to them below.

https://git.sr.ht/~webb/murse
https://lists.sr.ht/~webb/murse
https://lists.sr.ht/~webb/murse-lowfreq

The links on spiderden.net will be updated shortly. Future release 
binaries will be on the new repository.

murse v0.3.2 has been released.

This fixes a bug that prevents murse from deleting folders with 
children. If you were having issues upgrading or verifying, they should 
be fixed now.

https://git.sr.ht/~welt/murse/refs/v0.3.2

Changes:

- Switch to os.RemoveAll in all circumstances, fixes issue with TVN
   repositories that don't specify all the children removed, as well as
   directories with custom content.

In murse v0.3.0, signing support was introduced. There is a bug in the 
code for the verify subcommand that causes it to ignore the supplied 
key, allowing an attacker to create directories and delete files.

For Open Fortress players, this does not affect you as of this post; 
signing is not enabled on the servers (so you already have to trust the 
mirror you use.) However, once/if signing is available, then 
verification will be vulnerable to the issues.

To mitigate the issue, simply upgrade to v0.3.1. Downloads for v0.3.0 
will be removed shortly.

This bug is caused by a simple typo. In murse, there is a Client object 
that handles downloading and verification of revisions.

murse v0.3.1 has been released.

This is a security release, fixing a bug in verification with signing. 
More details will come in a follow-up post. Users should upgrade as soon 
as possible.

https://git.sr.ht/~welt/murse/refs/v0.3.1

Changes:

- SECURITY: Fixes a bug that caused the verification command to ignore
   the supplied key, allowing directories to be created before properly
   stopping the program.

murse v0.3.0 has been released.

As mentioned in the previous announcement, this update is a transitional 
release in preparation for some breaking changes. For more information 
on that please refer to the previous announcement.

For repositories using the new format for revision files, signatures can 
now be checked by using the -s/--verify-sigs flag and piping the key to 
stdin. It does not accept a file argument.

murse upgrade open_fortress -s < file.pem
curl https://example.com/key.pem | murse verify -s -r game_dir

The toaster has been fixed, if you've had problems with it you can use

TVN has gone through some specification changes that require breaking 
changes in murse. In particular, the format used for revision files have 
been changed to include the revision number to prevent reordering 
attacks with signatures. This was done to enable the community to mirror 
the game files while ensuring they haven't been tampered with, as well 
as allowing people to download the game on untrusted networks.

The next non-patch release (0.3.0) will be a transitional release. It 
will support both the new format and the old format for upgrades and 
verification, but in a future non-patch version it will be removed. I 
expect 0.4.0 to remove this unless circumstances change.

What does this mean for Open Fortress players and server owners? Now's 
the time to upgrade murse in preparation for signing. 0.3.0 will

This sounds extremely similar to MasterPlan. It's not free software but 
it is source-readable.

https://github.com/SolarLune/masterplan

I was gonna write an article about IsaacScript but you've beaten me to 
it. Good article.

I'm the one who did that long rant you quoted in Lamb's Discord guild 
(with the spider emoji as the username).

 > From a skim of the outputted code [IsaacScript] seemed to have 
quadrupled the line count in most of the functions I looked at compared 
to normal Lua (ignoring the branching functions where it tries to 
emulate some features)

I wanted to include more details about what I was testing at the time, 
and share some data and source code.

(Resending because I messed up the mailing list)

Time for some cope seething over one of your blog posts.

I agree that Matrix is bloated, but I disagree with basically every 
other point you made against it and for XMPP.

 > The Matrix protocol is very complex and unorthodox, which means that 
independent developers looking to develop a server software for it are 
looking at a large amount of work and testing.

What you're saying about effort would be true for anything, including a 
complete, usable XMPP server. In terms of the Matrix landscape I see 
more actually impressive/usable projects than I've seen in the XMPP world.

name: welt
link: https://welt.spiderden.net