Closed markfodor closed 9 months ago
Hi,
There is some very good stuff here. First of all I have to learn how to persist sensitive data in plugins before starting this. I do not wan't to store in clear passwords or in unsafe places. And obviously, not "commitable" in clear.
So to resume what are the key points of this feature :
I think for the 4 and 5 point, I'll consider them later. I think it's better to focus on simple and valuables points before. So the 1 to 3 points are my first focus.
Also I'm curious on the best scope for a stored password. For me, where I work, the file is the best, because all the files could have differents passwords for the same repository. I'm pretty sure the "whole project" scope will be an issue for most of people. and the folder scope could be counter intuitive. So my first choice is to bind a password to a file.
Second thing, how the user can "forget a password" for the encrypt action ? I think the best is to prefill the password input in the dialog, letting the user changing it if he wants.
Hi,
Yeah, good summary! I have a similar case as well: one environment file - one password. So I can agree with your reasoning.
About the second I can give you a real life example. In our team the person who does the encryption and the actual deployment could be different. So for the person who does the second step, it would be easier just to provide one password and he/she could check on all the encrypted values in the env file before the actual deployment. And of course, the encrypted values could grow with time, so prefilling seems like a good option.
So I think I managed to get at good state on this.
I added the remember password option on encrypt/decrypt dialog. The password is stored in the JetBrains PasswordSafe so : not stored in project file and is encrypted. Each stored password is bind with a file (absolute path) and I also keep the algorithm in that place. I added specific line marker to show if an encrypted string is valid with the currently stored password. Line markers are clickable and uncrypt string directly if stored password is correct, or trigger the uncrypt dialog if not.
I will provide a new beta version: 1.2.0.beta.4 When this version will be built and publish, after jetbrains approval in the market place, everybody that adds the beta repository on plugin can test it. If you're interested, I can explain to you how to do that.
Then after some tests, I'll publish it in the stable branch.
The new version is available for testing. If you want to test it, you have to add the beta channel list in the plugin repository. Add this url to beta repository: https://plugins.jetbrains.com/plugins/beta/list
Nice! I will test it tomorrow and give you a feedback. Looks good so far!
Okay, I have tested it with a few cases I could think of and it works like a charm. I honestly can not suggest any other changes at this point. Everything I tried comes naturally and it makes the whole plugin easier to use.
Great job you did there! π₯ We are waiting for the official release. π
Thanks for the testing !
I also force asked some collegues to test it. After that I'll release it.
the 1.2.0 version is now live. So I'll close this Issue
Thanks for the effort! I will keep you updated if we find something useful.
Is your feature request related to a problem? Please describe. No, it is a feature request.
Describe the solution you'd like It would be nice if the plugin could remember the previously used master password so it would make it much easier to work with multiple projects/subproject in the same repository. A possible scenario is that the plugin asks the user after an encryption/decryption if he/she wants to save it for later usage.
Describe alternatives you've considered Remembering one master password related to one environment file could work for most of the cases, but it is also possible to define multiple environments in the same file. Would it be possible to bind an encrypted text to the master password? (It is just an idea)
Additional context Take security into consideration, so even if the jasyptplugin.xml would be committed by accident it would not leak any passwords.
Possible next step: This feature would make it possible in the future to do a little code analysis and mark an encoded value as an error (red underline?) if that can not be decrypted by the provided Jasypt password.
Thanks for the effort you put into this plugin so far. The team really appreciates it! π