+1 for open repository
I hate to say it but for such a sensitive piece of software, not having a public repository that allows public tracking of source changes seriously undermines confidence in the integrity of the code. Especially since you have obviously put a great amount of effort into building an effective and secure tool for storing sensitive data. It seems strange to skip this one simple step, honestly i couldn't create software without version control :P
Sourceforge provides a solution for this, alternatively Github provides free GIT hosting for open source projects
Exactly. After noticing there isn't any public repository for this project. I'm not going to use it. (in fact I haven't even used it and it will be so)
Source code for released versions is at https://sourceforge.net/projects/keepass/files/.
I was going to fix a bug (KeePass is completely unusable in another Windows user account) and submit a patch... until I found out that there is no source control. No offense, it is absolutely ridiculous in this day and age. I refuse to download and make a change to the source zip file. I guess I'll look for another open source tool...
KeePass is an open source project. It releases the source code for version releases so that they may be audited, compiled or customized as the user sees fit.
KeePass is not a group or community project that allows users/developers to make contributions to its code base directly. As such there is no need to support public revision control.
Users who discover bugs may document and report them, and/or submit proposed patches. The developer has a long history of timely updating and bug fixing.
wellread1, I appreciate that you try to defend the maintainer's position, but that won't get me to contribute to this project. This 70's work flow model is just a pain (have to do this at work with one other open source project) and I rather look for alternatives in such a case. Luckily, there are alternatives. Good luck to the maintainer, but with so many excellent SCMs around it is beyond my comprehension how someone still prefers zip files. Too bad, it looked like a really cool project to contribute to, but I guess he's doing everything he can to discourage that. I'm evaluating alternatives, and I will not submit any patches as long as there is no SCM in place. Too bad...
The final product is evidence of appropriate and effective project management. For your information, ridicule is not a cogent argument. Nonetheless I am sure you will find a password manager that suits you.
Of course, Dominik has every right to use/not use VCS as he chooses.
However -- As open source software under the GPL, we as the users have every right to maintain a fork of KeePass using a more open VCS and open patch contribution processes.
Add my name to the list of people strongly interested in maintaining a GitHub fork/mirror for KeePass. Has anyone started one already? I'm confident that if someone starts a GitHub fork, that project will see increased contributions and attention...
These days we really need to consider and audit where our Crypto comes from; I'm very concerned for reasons already stated in this thread regarding lack of openness.
If you are keen to maintain a repository I'm sure Dominik won't mind you creating one from the source.
There's https://github.com/rassilon/keepass, and I'm sure I've seen an SVN one somewhere too, but I can't find it now. None seem to be actively updated with new releases.
Seems like the sort of thing that ought to be automateable - download the new source zip file, commit its contents to a repository to maintain an exact mirror of keepass source as released. Then you could base forks off of that, and pull in changes from official keepass releases as a manual process (fixing up any breakages of forked code).
I am not volunteering to run this, though!
I have a repo on github that is up to date with KeePass 2.x source. It is just the official releases, not really a fork. But, you can see exactly what changed from version to version.
Also, I have started a fork of KeePassLib for a project I am working on, with the intent that it could be shared with other .NET/Mono based projects, like KeePass2Android. This is just the backend - no user interface stuff.
There are also the debian and ubuntu source packages if you want to contribute fixes specific to those.
Didn't take me long to find this thread, but nonetheless could someone commit a README pointing to the Files area, just to help new arrivals who expect the code to be under the project's Code section when there is something under the Code section?
Documentation (i.e. README equivalents) is maintained at http://keepass.info/. Links to the official source code for all released KeePass versions is at the bottom of the Downloads page in the other "Other Downloads and Resources" section. The direct link is https://sourceforge.net/projects/keepass/files/
Links to third-party (unofficial) repositories are not listed in the documentation, but you can find them in this thread.
Related discussion on prism-break.org:
I completely agree with this old thread. It would be awesome that the main repo is maintained publicly (especially in GitHub, but others would work). Otherwise I don't think this would be considered Open Source Software... this type of sharing of the source code is typically called Shared Source or Source Available software, which it's a lot better than closed source, but it could be so much more.
In particular, this project would benefit from a lot of contributions so that the owners are not a bottleneck. In particular, I would definitely like the Android projects to become part of this... I'm always paranoid when downloading an unofficial port through the store.
KeePass is open source because the source is open. It is not collaborative in the way other software is, which may be a good thing for security software - we don't want insecure things incorporated, either by mistake or deliberately.
What are these beneficial contributions? Where is the bottleneck?
Your concern with unofficial ports should also apply to KeePass. How do you know KeePass is safe to use and other ports are not?
Paul, don't get me wrong, I really appreciate what you are doing, it's just that all the effort is just on you, when there's a lot of passionate good devs out there that want to help. Being open to contributions doesn't mean blindly accepting all contributions and have insecure things being incorporated. Only the committers/owners have write access to the repo, and you can be VERY rigurous in the reviews and not accept them until they meet the security and code styling standards that you define.
With regards to unofficial ports, given that there are so many and some not open source or not managed by someone we trust, we can never know if they have a backdoor or what. If a port is incorporated as part of the official github account (in the same or in a sibling repo), then it would have a lot of eyes on it, so the entire community benefits of that especially in terms of trust, but also in getting better software because of the contributions that top people around the world submit.
Regarding the "Open Source" naming technicality, I did not invent it. For example, see the definition here: Open Source vs Source Available in Wikipedia.
I did write Shared Source software for several years in the same way as you when my company's policies didn't allow us to fully open source our code. We were as open as we could, but we just couldn't take feedback in the form of code. Once our company endorsed open source, the productivity of our team and the project sky-rocketed, and the code quality was preserved or even strengthened.
The very link you give to Wikipedia supports the idea that KeePass is open source! That link says "shared source" is "where the source is available for viewing, but which may not legally be modified or redistributed". That does not apply to KeePass at all! There are not any restrictions I know of on modification or redistribution. There is even a nice Visual Studio project and plenty of documentation to let you build your own.
Every release has its source code made available. You are allowed to edit the source code. You are allowed to redistribute the source code. You are allowed to compile the source code and distribute that (if you can't, then it couldn't be licensed under the GPL).
What you have now is exactly the situation you'd have if the maintainers did every release in one commit. This actually happens in some open-source projects (e.g. Vim).
Software is "open source" according to https://opensource.org/osd if:
Software is "free" ( https://www.gnu.org/philosophy/free-sw.html ) if:
Nowhere in there does it say anything like "Software isn't free if it's not on GitHub".
Now...it certainly would encourage more people to contribute code to the project, if all development occurred on GitHub or BitBucket or Sourceforge. But the fact that development is mostly hidden until the release is irrelevant to whether the software is "free" or "open source" or not. It also has no bearing on how secure the software is; anyone can still examine the code of any released version. Anyone can still build any released version on their own if they don't trust the binary distribution.
It just discourages contributors. You don't like it because you want it done differently. Don't start making up other reasons.
All that said...actually I'd certainly like to see the source code maintained in a public repository as well, just to make it easier to pull updates when I am looking at the source code. But I'm not going to make a big fuss over it if the author wants to keep working the way he's always done it.
All right, very well explained, and it does make a lot of sense. I did not know the authors reviewed and took patches, and even without it, you explained well that contributions is not a must have for an open source project (for some reason I thought it was).
It just discourages contributors. You don't like it because you want it done differently
That is a true statement, my suggestion was not really to discuss the technicality of whether this is open source or not, but whether it should encourage contributions to make it much better. I did not consciously intend to use a fallacy (the open source technicality), that was just an argument in the wrong direction, and I'm sorry for it.
Techinicality and apologies aside, I would still like to recommend the authors to consider encouraging contributions but still being the shepards and the only commiters for the main repository. They can still never accept contributions that are not aligned with their goals or code quality or style. But with this, they won't miss out of really good contributions coming from thr right people.
Thanks a lot for your replies and for reading.
Patches / contributions are welcome, see this example in the Patches tickets.
If people won't suggest patches because they don't like the development model....
This is very disappointing.
Why is it dissapointing?
Does it make KeePass an inferior product?
Does it stifle development?
Is it not the way you want to work?
I think it's ok that KeePass handles contributions the way they do. It seems to work for them. It can be quite some overhead to manage many contributors, especially with security-related code, where reviews should be extra rigorous.
From the discussion here I get the feeling that some people would like to contribute something to the project but won't because there is no public repository. Having no repo makes the ongoing development process rather non-transparent. On the other hand KeePass doesn't want to change how they handle contribution or their development process (which is ok) by not getting a public repository.
But having a public repo doesn't necessary lead to change in KeePass' development process.
The problem here I think is that KeePass is using a technical barrier (having no repo) to reduce contribution when they instead should just be more open about how they handle contributions e.g. by having a faq entry explaining under what circumstances they accept anything (if at all).
The other argument against using version control because it would change the development process or create overhead ... well there are enough discussion about that on the web. Let's just say it seems very uncommon for a project of this size to not using version control. Most professional developers I know would use version control even for personal one-man projects because it makes them more productive - or sometimes just as a convenient way to backup code. I think that's what could be done with KeePass too. Instead of running your backup script (or going through your backup routine) just click the "commit" button in your IDE. You don't need to use any other version control features once the repo has been set up (which can be done within minutes). Merging patches could still be done outside of the vcs. It wouldn't be a common development practices but it would be something.
I think clicking on "commit" every other day/week/month or once in a while wouldn't change the way KeePass is being developed but would make a lot of people happy.
Contributions are always considered. See this thread for an example.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.