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
