hbons / SparkleShare

Share and collaborate by syncing with any Git repository instantly. Linux, macOS, and Windows.
https://sparkleshare.org
Other
4.88k stars 579 forks source link

Author gets encrypted #1857

Closed ubmarco closed 6 years ago

ubmarco commented 6 years ago

I installed Sparkleshare 2.0.1 from http://de.archive.ubuntu.com/ubuntu/pool/universe/s/sparkleshare/sparkleshare_2.0.1-1_all.deb on Xubuntu 18.04.

After creating a new encrypted repository on the server using dazzle, I synced the repository locally. When opening the history, I see all the authors are encrypted/hashed:

screenshot_2018-07-09_12-35-05

Also, when doing a git log on the repository, I see the same authors:

commit beb14cfe154e755cd30b583db980e94c7de5447d (HEAD -> master, origin/master)
Author: m0k6DJ7C8gAH47vEPOnF5g==_QjcRtNK0cyJ+XMsEQKISjg== <m0k6DJ7C8gAH47vEPOnF5g==_ZOXcq9ygSVnOVTolXgXDjFnWKEzVPT5QasOoTTDH/LE=>
Date:   Thu Jul 5 15:45:57 2018 +0200

    + ‘<path>’

commit a61e80ef2292d7ce460cc36bd7ca1c08009bf9e1
Author: U0vEbs1dfaSOKMhcvRM/nw==_GgfTu2w507L20pqx+qFSrQ== <U0vEbs1dfaSOKMhcvRM/nw==_SPCmqUo/4sLjKy9gzfg92eXH3DGdKEM5KJbyeGBesnQ=>
Date:   Thu Jul 5 15:33:05 2018 +0200

    / ‘<path>’

commit 58ba34fc20bac5f26e46d096841b244fe237304d
Author: KLhail48Pln4gIizegmZOg==_OAN7iZtEkAmBqmnvH3sY0Q== <KLhail48Pln4gIizegmZOg==_y4T2WMxs0FmIxU8OyRpBAItTa790HfHrw8oB7tdP+wc=>
Date:   Thu Jul 5 15:28:31 2018 +0200

    + ‘<path>’
    + ‘<path>’

commit e39fa756755d624899619506597bb05d1ed8c0e1
Author: OTNB0AYrQzBRSiUt/oUuuw==_D/lyKMMj4hWDE67I/oeL9w== <OTNB0AYrQzBRSiUt/oUuuw==_+g39RrkccCLNwgFR/iEFgoRmYM/Hpf3bkl/9+xQE3lE=>
Date:   Thu Jul 5 15:12:39 2018 +0200

    + ‘<path>’

I assume that's not a wanted behaviour?!

hbons commented 6 years ago

It's the expected behaviour, but it should be decrypted in the event log window. I guess this is because of encryption being broken for you reported in the previous issue?

ubmarco commented 6 years ago

I don't know if this is related. We both use Sparkleshare 2.0.1 now on Xubuntu 18.04 and recreated the server repo using the latest dazzle.sh script. First sync was with 2.0.1.

For testing purposes, we 1. created, 2. changed and 3. deleted a file named Message_2_Marco.txt in the root of the repository. Here is the history view: screenshot_2018-07-09_14-56-21

As you see, the symbols always show a +, but it should be +, edit and -. It looks like there is an issue with the path naming, it's truncated and only the ending part is shown.

In log, it looks like this: 14:49:25 Cmd | sync | git --no-pager log --raw --find-renames --date=iso --format=medium --no-color --no-merges -- "e_2_Marco.txt" And this surely returns nothing, so the history cannot be reconstructed.

Strange is that my name gets decrypted when introducing new changes but in changes from my colleague that's not the case.

hbons commented 6 years ago

Only newer SparkleShare versions encrypt the author information. That's why it looks mixed. The cut off file names issue has already been fixed.

ubmarco commented 6 years ago

Strange. The problems occurs only on my machine. On another machine, I added the project initially and the history correctly showed the authors with version 2.0.1. Then, on the machine having the error, I did a fresh sync and the problem disappeared.

The history of our repo now looks like this:

* 10df0d7 12 hours ago C1fVEkOCOMlEb0/tlqhEgA==_fTWl9kcmoG/ni9bHbKyY9A== (HEAD -> master, origin/master, origin/HEAD) / ‘another_test.txt’
* a8cc88e 12 hours ago lyC75VfxKxiE1/U6ToFBdg==_I93g86DrRhR5rcsWP3uqWw== < ‘another_test.txt.txt’ > ‘another_test.txt’
* 0867de1 2 days ago Marco Heinemann + ‘another_test.txt.txt’
* 0e667fd 2 days ago /1CBJNYRpUElT6sI1n18WQ==_UeZlVaFij0KDEtP3hu2UsA== - ‘new_file_added_180709_1537.txt.txt’
* 17cec4c 2 days ago Marco Heinemann + ‘new_file_added_180709_1537.txt.txt’

So it looks like some commits were created with an old Sparkleshare version which does not encrypt. However, I don't use 1.5 anymore.

After all I assume I did something wrong and the ticket can be closed. If me or anybody else encounters such a problem again, we can re-open the ticket.