Hi, On Thu, Sep 12, 2019 at 09:08:04PM +0200, Michael Kesper wrote: > > Since I do not have much experience with hashlib I'd be happy if > > someone might be able to proof-read `def Save_Cycle` in > > save_load.py. > > This does not have anything to do with hashlib per se. > It's just the usual mess of mixing bytestrings with strings. > You often don't notice in Python2, it just introduces subtle bugs. > Python3 is more strict here and doesn't allow it. > > Try this: > > tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
Thanks to this hint and the other hints by Peter Green, I'm now a bit further. > As an explanation: > > Python 3.7.3 (default, Apr 3 2019, 05:39:12) > ... Thanks as well. > P.S.: The code is in a bad state regarding whitespace / indentation. > This is critical to get right in Python (e.g. after a for there _has to_ > be an indentation added, Python normally uses four spaces, no tabs). I'm aware that the code is not good - there are other issues than spaces and tabs for instance I removed an instance of os.tempnam where upstream simply had overridden the automatic warning. Its unmaintained upstream as well. I've seen other code in Debian which is not good as well. Its rather a philosophical question whether it is better to drop it from Debian (and leave its users alone may be fiddling around with the upstream code themselves) or whether we try our best to make the code at least acceptable. I usually subscribe to the latter and think there is no right or wrong here. I'm not really sure whether we might manage in this case. After implementing all hints I'm now stumbling upon: Traceback (most recent call last): File "/usr/bin/cycle", line 83, in OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave))) File "/usr/share/cycle/p_rotor.py", line 63, in encrypt return self.cryptmore(buf, 0) File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore c = rotors[i][c ^ pos[i]] TypeError: unsupported operand type(s) for ^: 'str' and 'int' I think an "int(c) ^ pos[i]" could do here - but I'd like to get some confirmation first. Kind regards Andreas. -- http://fam-tille.de