From me at cv.gd  Wed Jul 15 15:42:08 2026
From: me at cv.gd (Chris Vigelius)
Date: Wed, 15 Jul 2026 15:42:08 +0200
Subject: Several issues found while setting up mandos on Ubuntu
Message-ID: <42228f18-9e83-4bb2-b5a9-071b756f290f@cv.gd>

Hello,

I have recently deployed mandos on some servers and encountered some 
bugs and issues:

1. server not working on Ubuntu 26.04 / Python 3.14

On 26.04, there is an AttributeError/PickleError as soon as the first
check is successful and mandos tries to pickle the result:

AttributeError: module '__main__' has no attribute 'ClientDBusAlternate'
...
_pickle.PicklingError: Can't pickle <class 
'__main__.ClientDBusAlternate'>: it's not found as 
__main__.ClientDBusAlternate

(see also attached log mandos_pickle_error.txt)

This problem does not appear on 24.04 / Python 3.12 with 1.8.19.

2. monitor broken on Ubuntu 26.04 / Python 3.14

Starting mandos-monitor results in ModuleNotFoundError:

Traceback (most recent call last):
   File "/usr/sbin/mandos-monitor", line 41, in <module>
     import urwid.curses_display
ModuleNotFoundError: No module named 'urwid.curses_display'

Note: urwid.curses_display IS installed and while "import 
urwid.curses_display" does not work, "from urwid import curses_display" 
does. I have no idea why.

This problem does not appear on 24.04 / Python 3.12 with 1.8.19.

3. mandos (server) package should depend on fping

The checker uses fping by default and fails if this package is not 
installed, marking the hosts as disabled.

4. mandos-monitor shows deprecation warnings (minor)

datetime.utcnow() is deprecated as of Python 3.12, which causes python 
to show warnings (breaking the urwid display). Replacing it with
datetime.now(timezone.utc) should solve this

5. Docs could have a "Getting started" section (minor)

Even though the docs and manpages have good reference documentation, it
is difficult for new users to figure out what to do to get started. 
Something like

"Install mandos-client on the client you want to automatically unlock, 
and install mandos on another server. Now run mandos-keygen --password 
on the client, enter the necessary password and copy the resulting 
config into /etc/mandos/clients.conf on the server"

would help a lot to get on the right track. The front page or the intro 
man page would be a good place for that IMHO.

best regards,
  Chris



-------------- next part --------------
root@[redacted]:/etc/mandos# mandos --debug
2026-07-15 13:15:12,322 mandos [1380449]: DEBUG: Did setuid/setgid to 132:136
2026-07-15 13:15:12,406 mandos [1380449]: WARNING: Could not load persistent state: No such file or directory
2026-07-15 13:15:12,407 mandos [1380449]: DEBUG: Creating client '...'
2026-07-15 13:15:12,407 mandos [1380449]: DEBUG:   Key ID: BA...FE
2026-07-15 13:15:12,407 mandos [1380449]: DEBUG:   Fingerprint: 5E...7D
2026-07-15 13:15:12,411 mandos [1380449]: INFO: Now listening on address '::', port 57155, flowinfo 0, scope_id 0
2026-07-15 13:15:12,412 mandos [1380449]: DEBUG: Avahi server state change: 2
2026-07-15 13:15:12,413 mandos [1380449]: DEBUG: Adding Zeroconf service 'Mandos' of type '_mandos._tcp' ...
2026-07-15 13:15:12,413 mandos [1380449]: DEBUG: Starting main loop
2026-07-15 13:15:12,414 mandos [1380449]: DEBUG: Avahi entry group state change: 1
2026-07-15 13:15:13,374 mandos [1380449]: DEBUG: Avahi entry group state change: 2
2026-07-15 13:15:13,374 mandos [1380449]: DEBUG: Zeroconf service established.
----------------------------------------
Exception occurred during processing of request from ('fd00:...:6fd2', 59090, 0, 0)
AttributeError: module '__main__' has no attribute 'ClientDBusAlternate'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.14/socketserver.py", line 318, in _handle_request_noblock
    self.process_request(request, client_address)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/sbin/mandos", line 2614, in process_request
    proc = MultiprocessingMixIn.process_request(self, request,
                                                client_address)
  File "/usr/sbin/mandos", line 2600, in process_request
    proc.start()
    ~~~~~~~~~~^^
  File "/usr/lib/python3.14/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.14/multiprocessing/context.py", line 230, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/context.py", line 306, in _Popen
    return Popen(process_obj)
  File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
    self._launch(process_obj)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 47, in _launch
    reduction.dump(process_obj, buf)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
_pickle.PicklingError: Can't pickle <class '__main__.ClientDBusAlternate'>: it's not found as __main__.ClientDBusAlternate
when serializing ClientDBusAlternate class
when serializing ClientDBusAlternate object
when serializing dict item 'odin'
when serializing dict item 'clients'
when serializing MandosServer state
when serializing MandosServer object
when serializing tuple item 0
when serializing method reconstructor arguments
when serializing method object
when serializing dict item '_target'
when serializing multiprocessing.context.Process state
when serializing multiprocessing.context.Process object
----------------------------------------


From zen at torproject.org  Tue Jul 14 20:33:18 2026
From: zen at torproject.org (Zen Fu)
Date: Tue, 14 Jul 2026 15:33:18 -0300
Subject: mandos-client suppresses NULL characters from passphrases
In-Reply-To: <87echpgtek.fsf@recompile.se>
References: <87a4sdk1v0.fsf@localhost> <87echpgtek.fsf@recompile.se>
Message-ID: <87v7ah5slt.fsf@localhost>

Hello, Teddy!

Thanks a lot for reviewing this. i think you're right, we had one
password with the NUL character that worked with Mandos before we
started using Debian's keyscript=decrypt_keyctl[1] and started failing
after that.

[1] https://cryptsetup-team.pages.debian.net/cryptsetup/README.keyctl.html

i'll route the bug report to the appropriate place, sorry for the noise
and thanks again for your time on this on checking, answering, etc!

--

Teddy Hogeborn <teddy at recompile.se> writes:

> "Zen Fu" <zen at torproject.org> writes:
>
>> Hello, Mandos devs!
>>
>> We're using passphrases randomly generated from /dev/random, and i
>> noticed that mandos-client suppresses NULL characters before handing
>> the passphrase to stdout. With --debug, the passphrase is printed
>> correctly in the output log, but for some reason when printing the
>> passphrase to stdout the NULL character is not printed, resulting in
>> the wrong passphrase.
>>
>> I hope this is the correct place to report bugs.
>
> Yes, it is.
>
>> Steps to reproduce:
>>
>> - generate a passphrase with a NULL character (that's hex 00)
>> - use mandos-client to retrieve it
>> - see that the passphrase output suppresses the NULL character
>
> I'm sorry to report that I cannot reproduce this.  I can generate a
> password containing NUL characters, and it is output correctly by
> mandos-client.  I have also reviewed all the code involved in the
> copying of the password bytes, and all of the code handles the password
> as a buffer of bytes with a length, and never looks at the actual bytes.
>
> I strongly suspect that it's whatever you have reading the password
> which is suppressing the NUL character.  I do note that the systemd
> Password Agents protocol? might be interpreted as implying (but does not
> explicitly state) that NUL bytes terminates the password.  Regardless,
> when using a systemd-based initramfs image, we do send the entire
> password (NUL bytes and all) to the indicated socket (including an
> additional terminating NUL byte, as allowed by the protocol), but the
> recieving end might do anything.
>
> 1. <https://systemd.io/PASSWORD_AGENTS/>
>
> /Teddy Hogeborn
>
> -- 
> The Mandos Project
> https://www.recompile.se/mandos
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev
-- 
Zen Fu