-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Place LoRaWAN keys in a separate file, separate from source code and application configuration settings #184
Comments
@lnlp I like the idea of having one central location for the keys and happy to assist you with creating a PR for this. I'm interested in learning from you:
|
Yes.
Why should I?
I can create a PR for implementation phase 1. FYI: The concept of using a separate LoRaWAN keys file is already successfully applied in LMIC-node. |
@lnlp you mention
How are you targeting specific applications?
Some apps like basic and secure_element_lorawan and many future apps might not use soft SE!
What is your proposal? considering the current structure?
I think the current structure provides this flexibility if the user excludes all of the conf folder in his .gitignore
I have no problem that we fix this and hence why #56 exists, but I think we need to do it on per-application basis. Your solution is a good improvement for readability if we do it for each application that uses Soft SE I have a suggestion around this:
At the end, this solution will look like a simplified Please keep in mind we would like each app to be standalone. |
How is it currently done and how does the user currently know? There is not much that changes in that aspect.
So what's the point here?!
As already suggested: put keyfiles in folder Talking about locations, I would even like to suggest to split up the repository in two separate repositories. One dedicated to software (development) and the other dedicated to hardware (development). Both have a very different pace of development and a software engineer will not be interested that much in the hardware repo and the hardware engineer will not be that interested in the software repo. Different versions of the software should be able to run on a single version of the hardware and a single version of the software should be able to run on different versions of the hardware. I don't actually see the benefit of combining hardware and software development in the same repository for users of the repository. It only gives overhead and requires an extra directory level.
That may be your view but I do not fully agree with that, especially for keyfiles. If there is any user configurable / device dependent configuration data in these files then placing that configuration data in the source tree of a library would be bad practice.
I have no problem with renaming lorawan-keys.h if for good reason and clear to the user.
To store keyfiles you mean. Yes, you could but my suggestion is to place keyfiles centrally where they can be shared by all examples (and if the user has reasons to do it otherwise (s)he can adapt the code accordingly (simply change the path of an include file). You must make it easy for the user where possible. Being able to share keyfile(s) is importantso the user only needs to provide a single lorawan keys file in a single location (and it should be easy to switch keys for testing purposes and for uploading the same application to multiple devices). If the user wants to customize or put a single example in a single repository it's dead simple to only change the path of the include file in the code. Tip: lorawan-keys.h can only contain an
Yes, assuming that you mean in the end
Using a shared keyfiles folder does not prohibit that. But if an app is to be 'extracted from the repository by the user' to be used stand alone, there is nothing wrong that in such case the user needs to update the include path for the Making the user having to copy the same keyfile to all (relevant) LoRaWAN example applications and have to repaeat again for every change does not make things easy for the user so I still suggest to use a central keyfiles folder.
Yes, I think that is a good thing. On the other hand it will aslo be useful to additionally have an example app where the user can simply configure which of both options to use (this will clearly demonstrate what is common and what is different between the two). |
@lnlp Please feel free to open a PR if you would like to contribute or I can implement this later in the coming months myself as I don't see it as a priority and the proposed change could break functionality. Please follow our contribution guideline and please be aware that your PR doesn't have to be merged, especially if we feel it creates more issues than it solves. |
@marnixcro can you take on this issue, it's a low priority but it is a good idea to investigate a proper easy solution for handling the keys. |
any updates here? |
Summary:
Place LoRaWAN keys in a separate file, separate from source code and application configuration settings
Why do we need this?
(or configuration files where LoRaWAN keys are mixed with application settings).
What is already there? What do you see now?
LoRaWAN keys are currently defined in file
app_conf.h
where they are mixed with regular application settings.This has several disadvantages (see why do we need this above).
What is missing? What do you want to see?
Separation of LoRaWAN keys from source code and from application configuration files.
How do you propose to implement this?
Create
Software/keyfiles
folder for storing key files that can be used by all LoRaWAN examples.In this folder add file
lorawan_keys.h
which contains the actual keys.In
se-identity.h
#includelorawan-keys.h
instead ofapp_conf.h
and remove the OTAA keys fromapp_conf.h
.Exclude the contents of this folder and any keyfiles from the repository (in
.gitignore
).Add file
lorawan_keys_example.h
to thekeyfiles
folder and DO include the example in the repository (in.gitignore
).This example file can be copied to
lorawan_keys.h
by the user for adding the LoRaWAN keys for a device. Thelorawan_keys.h
file will be excluded from the repository so the LoRaWAN keys will not be (accidentally) uploaded to (public) repositories.File
lorawan-keys.h
can include both keys required for OTAA and ABP (use the ones appropriate).To make things even easier for the user, clearly indicate which keys are required for OTAA and which for ABP (by prefixing the key names with OTAA_ or ABP_).
When preferred the
keyfiles
folder can contain multiple keyfiles, e.g.testdevice1_lorawan_keys.h
andtestdevice2_lorawan_keys.h
.The files contain the actual keys ('are copies of lorawan_keys_example.h') and file
lorawan_keys.h
only needs to contain an include statement like#include "testdevice1_lorawan_keys.h"
. This include statement can be easily edited as needed to use one of the other keyfiles without requiring any modifications to application source code or application settings.Environment:
Not relevant.
Acceptance Criteria:
No specific acceptance criteria.
What can you do yourself and what do you need help with?
I will create a PR for my code where this has already been implemented.
I need help from TTI to merge the changes from the PR so everyone can benefit and use this functionality.
The text was updated successfully, but these errors were encountered: