Fixes issue26: outdated FIRMWARE version

[frickler24]

The file FIRMWARE in the root directory of ckb-next is signed.
Therefore, updating the obsolete content was not possible by anyone.

A new key has been created, with which only signatures for this development
should be made (ckb-next@frickler24.de, BAF07C6B).
The key was self-signed and in addition signed with my personal key.
It should also be signed by mattanger and possibly others.
Caution: The key may not be exported as ASCII file, but only as a binary file!

The display of gpg -d FIRMWARE should do something like this:
Gpg: Signature from Sat 04 Feb 2017 11:59:11 CET using RSA key ID BAF07C6B
Gpg: Correct signature of »ckb-next (For signing development artefacts only!)
Ckb-next@frickler24.de«

To test the function, the signed FIRMWARE file was originally uploaded to a branch of mine:
https://raw.githubusercontent.com/frickler24/ckb-next/issues-26-Firmware-Incident/FIRMWARE
(in line 36, kbfirmware.cpp).

In order for the mechanism to go productive,
the FIRMWARE file of the MASTER branch must be updated!

To prepare the mechanism fpr production,
the link ist updated to the MASTER branch FIRMWARE file:
https://raw.githubusercontent.com/mattanger/ckb-next/master/FIRMWARE

---

• Therefore this patch must first be used in master branch
• so that the correct file and key can be loaded at runtime.
• Then the patch can be added to the testing branch and others.

---

If the file or the key in the master branch is not up-to-date,
an error message is displayed when the ckb client is started
(as an example, here a possible error message):

Gpg: Signature from Thu Jun 30th 2016 09:15:49 CEST using RSA key ID 8DC8D309
Gpg: [do not know]: invalid packet (ctb = 2d)
Gpg: keydb_search failed: Invalid package
Gpg: Can not check signature: Public key not found

.gitignore is updated to ignore a directory containing tmp-files
and a script for signing the FIRMWARE-file.
If it is interesting for others, I can commit it also.

[tatokis]

@mattanger already had a new key for this purpose. Not sure what happens now.

[frickler24]

OK, then take mattangers.

[ghost]

I hope @mattanger can clear things up.

[ghost]

typo in "Lastz"

[frickler24]

Thanks, Will be fixed with the additional K70 Infos.

[frickler24]

Currently I'm still updating the information for the K70 variants.
@ Mattanger asked in the issue thread for my solution. If he has a new key, he can update the information most easily in the source code after merging the pullreq.
If he does not already have a new key, we should exchange the key generated by me. When I get his public key, I can send him my private key encrypted.

The current Information (all K70 except the K70 non-rgb) is here

[ghost]

Please add an rgb version too, I've updated the comment in #55.

[frickler24]

@light2yellow add an RGB version for the rapidfire or another one?

[ghost]

Yes, k70 rapidfire.

[frickler24]

OK, I found it. it is call K70RGBRAPIDFIRE with v2.05

[frickler24]

I can update the FIRMWARE file, but anyone who owns that keyboards should give us the correct information from the model files. With this information, fwupgradedialog.cpp must be updated also (the KbId ids[] array).

[ghost]

Okay, you can probably just comment it out for now. On irc I proposed creating a separate issue that would track the current support status of different keyboards (some of them are fully supported (I suppose), some of them are supported in an add-and-pray style with just the array of models being updated) just to keep track of everything (we already have k65-related info "somewhere"). Because I didn't follow the project for these two years I don't know what level of support is provided for the keyboards listed in Readme, I can only tell that my own keyboard (Strafe RGB) seems to be fully supported.

[frickler24]

The automatic update (at least the search for it) should run with an updated FIRMWARE file.
As I mentioned in the recent commit, the line with the correct firmware download-site etc. is searched dynamically by other factors. The ids-array seems to be used in the manual update dialog only.
Because that dialog did not work for me when I last needed it for the mouse FW upgrade, I will have a look at it next. But first I need some testing for issue 48 :-)

[mattanger]

Sorry I've been out. @frickler24 & @tatokis I do have this key. I'm going to merge the PR and update the source with the new key. Thanks for working on this! You're obviously contributing a lot, so hop on IRC or lemme know if you're interested in being a maintainer.

[tatokis]

@frickler24 Apologies if my reply came off as negative. That was not my intention, I was genuinely not sure what to do.

Also, suggestion, maybe use RFIRE instead of RAPIDFIRE to save characters, just like we do in usb.h?

[ghost]

@frickler24 should the FIRMWARE file be gitignored?

[frickler24]

@light2yellow The FIRMWARE file is loaded by the ckb client when it checks for firmware upgrades directly from the github repo. If we gitignore it, it will outdate in the repo.
The client does not need a local FIRMWARE file, but is there a way in git to handle the file in github, but not in the clone-able repo?

[tatokis]

You should be able to unstage it before doing a commit.

If we gitignore it, then there won't be a way to update it on the repo, unless I am mistaken.

[frickler24]

@tatokis good idea to reduce the string length. I've done it in the last commit.
Thanks for your comment about your intention. No problem, I think we have enough to fix in this project and I wanted to avoid different solutions.
Another question: How should we track the other things which have to be done for the firmware-versions?
usb.h has a lot of good entries, but in usb.c, const char* product_str(short product) must be completed.
Open a new issue or track it here?
Is anyone working on this yet (@mattanger ?)

[frickler24]

@mattanger collaborator would be nice. I have good experience in C, some in C++ and a very little in git.
For my english translations google will help...

[mattanger]

@frickler24 Awesome, and yes I'm working on this. What I'm going to do is merge in your PR, then re-sign the FIRMWARE file with the new key and replace the binary key you've submitted.

The .firmware directory entry in the gitignore, aside from housing the script you mentioned, is there any reason for it existing other than for your personal use? It's not a big deal, but I think its somewhat bad practice to add extraneous entries.

Lastly, I don't really see an issue with tracking the FIRMWARE file in the repo, while the client may not need it locally, it does give us a simple and convenient way to keep it updated.

[frickler24]

@mattanger you are right, the .firmware directory contains the following:

• the FIRMWARE file without signature infos
• a simple one-liner to sign that file with output goes to ../FIRMWARE afterwards
• the firmware files, downloaded from corsair. I needed this to get the sha256sum.
  I believe we are not allowed to publish these files, because they own corsair and I think they are copyright relevant. These files are the main reason why I gitignored the directory.

So you may delete the .firmware directory entry in .gitignore.
When I pull your master with the updated FIRMWARE, there is no need for it anymore and the commit is clean.

[mattanger]

Gotcha. I'm going to merge in what you have, then remove it on the next commit when I update the signed files. Thanks!

[frickler24]

Thank you for your work!