Duplicate ticker fix

[Vetro7]

I'm not trying to over post this issue, but the PR thread is a mess and I'm sure it is a full time job keeping up with it. We need the automated checks to be either updated or a solution to the issue of changing already merged files ( #24 ).

As you can see in my attempts to get #337 to pass the auto checks. I have tried this many ways, uploading 2 new files so that it only changes 2 files, fails due to "duplicate ticker"even though it is myself trying to update the info. These are running in to this issue as well here #384 #355 I'm sure I missed some, #360 was able to pass for now, it was brought from a fork that is 788 commits behind, so once you merge in master it will fail for "duplicate ticker".

I have also tried only changing the files that need to be changed. However doing so is looked at like 3 files being changed. This is bc the public key (file name) is being changed which normally would just look like a change. However the only other part of that file is the sig and it to is being changed, so this is looked at like a new file rather then changing one already merged. If there was more lines to the sig file or it was not labeled with the public key this wouldn't happen this way. I understand they need to be this way, so we will just need a solution moving forward for everyone that needs to update information like this.

[Vetro7]

Going a bit deeper into this, I'm sure you guys already have a plan for once this initial phase is complete and we have to maintain our records current. As I'm sure you already have ready a way for us to sign with an old key, before changing to a new key, to prove we are the original owner more then just our Github usernames. Maybe you could use one of those future solution for this, and have us sign for updates to a "duplicate ticker", maybe with an ed25519_pk1888888888.ver file to verify ownership and changes. Anyway just a thought, I don't like bring up bugs without at least an attempt at a solution.

[KtorZ]

Hi @Vetro7 , this is not a bug but an actual feature. We've limited the modifications to two files to make manual review easier and also, doesn't add too many level of complexity to the CI validation tool which is already complicated enough.

To be clear, you're trying to change the public key associated with a ticker which is something that is so-to-speak forbidden. If you could do it, then anyone else also could 😉 ! There's no issue with trying to update the rest of your metadata, but changing the public key and therefore, the ownership is not something you can do without the ticker being first given up by the owner (i.e., you).

To solve this, you'll need 2 pull requests:

1. A first PR that "voids" the ticker associated with your current public key (e.g. "VOID0")
2. A second PR, that re-register this ticker on a new public key (that can only be merged after the first one has been merged!).

As a result of 1., we could also remove the voided files altogether. We can't simply remove files on request by the way, because what proves that you are who you say you are 🙃. This is what the signatures are for.

[Vetro7]

Well then I guess we should probably inform the others that I have mentioned in this as well.

[Vetro7]

There will be plenty more as well, I will keep an eye out for, as the mnemonic function later release has caused this for most.

[Vetro7]

looks like you have a real bug in buildkite now.. as the VOID0 has passed but throws this error

#337

Success

--( Checks passed.

Running global pre-exit hook
$ /nix/store/7k8gr1s69hj9w243b0i59pd26g23kk72-buildkite-agent-hooks/pre-exit
rm: cannot remove '/tmp/systemd-private-9dbadb5665fb482d9be5843d34457d2e-nscd.service-zNqkqb': Operation not permitted
rm: cannot remove '/tmp/systemd-private-9dbadb5665fb482d9be5843d34457d2e-systemd-logind.service-DtbX1d': Operation not permitted

[KtorZ]

Yes, we are aware and actively working on it :)

See: #403 (comment)

[Heinrich-CH]

Hi, interesting discussion!
So, according to KtorZ, it isn't it just possible to "revert" the initial commit (graphically from github) and re-submit new files (tried in #427). I'll have to try to do the VOID way then.

[Heinrich-CH]

Ok, I VOIDed my initial commit (#433). But if I re-submit, the build will fail (old pool ticker still part of master). Can I leave #360 open for consideration? Or can it never be considered since the build failed once?

[KtorZ]

@Heinrich-CH #433 has been merged and I've just updated your branch on #360 to be on latest master. It's green and ready to be merged ;)

[Heinrich-CH]

Thanks so much for your hard work!

…

On Sat, Dec 14, 2019 at 12:20 AM Matthias Benkort ***@***.***> wrote: @Heinrich-CH <https://github.com/Heinrich-CH> #433 <#433> has been merged and I've just updated your branch on #360 <#360> to be on latest master. It's green and ready to be merged ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#394?email_source=notifications&email_token=ANSJTK4KB3FQ236WPGSOH5DQYQKDZA5CNFSM4J2KRNGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG3RJ3A#issuecomment-565646572>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANSJTKZ5LRZNFPF2JM7UYKLQYQKDZANCNFSM4J2KRNGA> .

[cardanohawaiipool]

Hi @KtorZ, I sent the email, but my original PR is #199.

[maneav]

Hi @KtorZ please delete my currently merged ARM1 pool #94 , then please review this pull request #544 and merge. Thanks.

[stakeada]

Hi @KtorZ, please delete my current pool #617 (has been VOIDed) and review the #618 (whose checks should also pass afterwards) and merge. Thanks