Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Source code repository for KeePass?

Anonymous
2011-04-11
2014-03-03
1 2 > >> (Page 1 of 2)

  • Anonymous
    2011-04-11

    The SourceForge page lists http://keepass.svn.sourceforge.net/viewvc/keepass/ as the project's svn repository, but it's been almost two years since the last commit there, which suggests that active development is happening elsewhere. Where is the main repository these days?

     
  • Dominik Reichl
    Dominik Reichl
    2011-04-11

    On my PC.

     
  • pfn
    pfn
    2011-04-12

    Indeed, I too wish it were hosted more publically, bitkeeper, github, etc.

     

  • Anonymous
    2011-04-12

    dreichl: Is there a reason for this? Not having a public repository tends to discourage contributions to the source… I'd be interested in implementing a feature or two, but the only way I can comfortably do that is if I know I'm tracking your development.

    If you're reluctant to host it on any of the standard providers (as pfn0 suggested, bitkeeper, github and others), I may be able to offer keepass free hosting of any scm of your choice… In any event, please consider this thread a strong request for publishing the keepass repository!

     

  • Anonymous
    2011-04-17

    Dominik: Could you please comment on your thoughts regarding providing a public development repository? Is this something you're willing to do in principle, but don't have time to arrange right now, or do you simply prefer the one-man development model with no contributions?

     
  • Paul
    Paul
    2011-04-17

    Dominik has already commented. I'll see if I can find the comment.

    cheers, Paul

     

  • Anonymous
    2011-04-17

    Yes, I saw that. It's 4 years old, though, and I was hoping evidence of continued developer interest in a public repository and/or time might help change Dominik's mind on this.

     
  • The repository at http://keepass.svn.sourceforge.net/viewvc/keepass/ is five years out of date.

    Where is the source code hosted? If it's not public, I don't see how it can be listed as "KeePass is OSI Certified Open Source Software" on the website.

    Please update the repository so users can review the code and contribute.

     
  • Dominik Reichl
    Dominik Reichl
    2012-02-20

    KeePass is distributed under the terms of the GNU General Public License (GPL). A link for downloading the latest source code package is always available on http://keepass.info/download.html (in the box 'Other Downloads and Resources').

    The GPL is an OSI-approved open source license, thus KeePass may use the 'OSI certified' logo.

    I'm not going to maintain a version control system. See the thread Paul has linked to; nothing has changed since then.

    Best regards
    Dominik

     
  • Julian Taylor
    Julian Taylor
    2012-02-20

    I also would really like to see a version control system used.
    Much has changed in the last 4 years, VCS's don't suck anymore like cvs and svn.
    git, bzr and mercurial are just plain awesome. With github or launchpad there is a free hosters with great features.

    I don't know how you handle development on your machine, but I can't imagine that it is more effective than the workflows git enables you to use.

    It is a real pain to review the thousands of line diff's on every release for the debian package. Especially as the last few releases were not free of regressions which had to be isolated in this huge diff (ok, the root cause was always mono but that had to be figured out first)
    Also the plugin developers would benefit to see when you change the api, so they can react earlier to breakage like in the case of keeforms.

     
  • I concur with jtaylor108 and others.

    It's also a lot to ask for you to be the one of the few people developing the software and then also hosting a personal repository especially considering the Bus factor(http://en.wikipedia.org/wiki/Bus_factor). KeePass is a popular project and hosting it on GitHub could allow more people to review security, contribute pull requests, and possibly bring in more donations.

    Currently, the lack of commit level transparency also raises concerns about the security of the software. Right now, it seems like there is a single point of failure and for the sake of the community and users, that should be resolved. 

     

  • Anonymous
    2012-08-10

    Not having a public repository on an excellent site like Github really discourages other from contributing.  I was just talking to a developer friend of mine - and realized that I wanted to add two-factor authentication (using Google Auth) for fun.  We looked and looked for the source code - and we're tremendously disappointed that it was a zip file.  No history.  No visible progress.  No easy updating.  Nothing.

    Things have changed - OSS development has moved to a truly transparent model…once a source control provider is setup -the overhead for the owner is minimal…and it's worth the small initial investment.

    I'll strongly consider maintaining a port at GitHub or similar if you aren't willing.  I love KeePass - and making it easier for others to develop on will only make it more useful!

    Please re-consider your views - I think the voices here represent a slice of those who truly care - I made a sf account just to make this comment.  Please pick a common OSS dev model using a great source control management system. :)

     
  • Dean Glazeski
    Dean Glazeski
    2012-08-10

    I'm going to agree with TheMirage, and many others in this thread, and say that some kind of repo should be setup.  Github is very nice and intuitive and I highly recommend you consider that.  I just recently started a repo for a KeePass plug-in that took all of five minutes to get established and cloned onto my local system.

    I actually have a series of bugs I would like to fix in relation to plug-in development and some of the command line switch handling, but it's very difficult for me to do patches when I don't know what you have done or what you are working on.  It would be to everyone's advantage to have an external repository so it's easier for us to contribute.

    I'll check back here in a few days and if there isn't any movement on your end to bring up some kind of version control system, I'll just take the latest source and set something up on Github.  I'll come back and leave a link here.  If you want to request access, I'll be more than happy to give you full commit access.

    Unfortunately, doing this without the support of the lead developer could make this new repo more of a fork of KeePass which is something I don't want to do.  At the same time, though, I'd like to create patch sets with the help of a version control system on my end and I can't do that without something to commit to (and doing this with my own local git repo seems silly to me for an open source project).

     
  • David Lechner
    David Lechner
    2012-08-10

    I know this is not exactly what people are hoping for, but there have already been a few KeePass "clones" on GitHub. I have a fork of one at https://github.com/dlech/keepass2 that I use for plugin development. It is just the release source code for each version from the keepass website.

     
  • Dean Glazeski
    Dean Glazeski
    2012-08-11

    Thanks for the pointer, dlech.  It doesn't solve all the problems, but hopefully it shows that there is some interest in a live, public VCS for this project.

    One point that I didn't make comes from some of the discussion from dreichl saying how there are few submitted patches.  One of the reasons for that might be that people lose interest in developing patches when they can't see the current state of development, as I almost am :).  The fact still remains, a lot of work has gone into this app and I'm still finding cool little features.  It would be great to keep it evolving.

     

  • Anonymous
    2012-08-13

    First - dlech27 - I did check out the repo, but as you mentioned, the value of that kind of repo is lessened since you still can't see the day to day progress and what's being worked on.  Those kind of diffs as a version-to-version difference are painful to look at and decipher what's happening.

    @dnglaze - You hit the nail on the head - it's an incredibly cyclical issue.  Hard patch submission = less patch submission = less incentive to create repo = hard patch submission =…..  Dominik has to break the cycle!

    For him it would literally be creating a GH repo, uploading the current source, and cloning locally.  Then he can just push.  Everyone else has to do pull requests of whatever.  It's painfully simple.  I mean, I really do appreciate his development efforts - and I'm incredibly happy he continues to develop KP - but it could far more open to features, customization, etc…with him still being the gatekeeper.

    Dominik - you don't have to lost control if you use a VCS like GitHub or similar…it just makes it extra-ordinarily easier for other developers to see what's going on and submit patches, suggestions, etc.

     
  • Hi Dominik,

    First I would like to thank you for the great software you are providing. KeePass is commonly used by IT specialists I'm working with. We are now checking the software we use to make sure that it is indeed open sourced and can be verified to be safe for use (e.g. contains no backdoors, spyware, malicious code etc.).

    I see no reason for KeePass (or any other open source project) to not be maintained under open source control. You must understand why keeping your code modifications private might decrease trust in your software. Theoretically, all you need to do in order to create an exploit is to add a backdoor to a newly released version. It doesn't even matter that you release the code - until someone realizes that the code you have released is different than the code of the software on your site, well, it might be too late (and will probably never happen in the current state of affairs).

    Please reconsider.

    Thanks,
    Shlomi Fruchter

     
  • Paul
    Paul
    2012-09-11

    Theoretically, all you need to do in order to create an exploit is to add a backdoor to a newly released version. It doesn't even matter that you release the code - until someone realizes that the code you have released is different than the code of the software on your site

    Or you release an EXE that was not compiled from the source code in the repository. There really is no guarantee unless you asses the code and compile yourself.

    cheers, Paul

     
  • Or you release an EXE that was not compiled from the source code in the repository. There really is no guarantee unless you asses the code and compile yourself.

    I agree. But consider the following scenario. Let's assume I trust version 2.1 of the product. Now I want to get version 2.2. So I only need to review the changes from 2.1 to 2.2 to make sure the software is safe. But because I have no change history, I have to review the entire code.

    Now, that can be solved by cloning the project and maintaining a separate copy of the code by some 3rd party, updating it for each version. But what's the point? Why won't you do it yourself, like most open source projects do?

     
  • Paul
    Paul
    2012-09-12

    It's personal preference and Dominik chooses to do it himself. Maybe one day….

    cheers, Paul

     
  • spocko
    spocko
    2012-09-19

    For whatever it's worth, I'll add my voice here as another person in favor of an open repository. The benefits have already been stated by others, so I won't repeat them. Even if the repository was read-only to everyone except Dominik for starters, it would still be very helpful.

    Thanks

     
  • Volker B.
    Volker B.
    2012-09-19

    +1 for open repository. i really don't see any reason what could be a showstopper not to use one.

     

  • Anonymous
    2012-11-13

    >>It's personal preference and Dominik chooses to do it himself. Maybe one day….

    Sometimes you have to set aside personal preferences for the greater good - especially if it will increase community involvement.

    Perhaps Dominik would get more participation if he left the 'development' code in an open repository where he is still in charge.  Nearly all top corporations use version control, and I feel like he hasn't given it a fair chance.  I make numerous daily commits to software I develop on a daily basis, and there is actually comfort, accountability, and audit-ability when you have commit messages, commit logs, etc.  This isn't the place for me to make an exhaustive argument for version control, but it just reeks of ignorance to simply say "not happening-it's too much work".  It's incredibly disappointing, and I'm actively searching out alternatives that I feel meet enough of my criteria just due to the apparent attitude here. 

    Something so trivial this day and age is only hampering the community involvement in this project.

    Intro to Git Slides

     
  • Paul
    Paul
    2012-11-14

    At the risk of alienating some of you I'm going in to bat for Dominik's choice. Please take this as considered argument, not discouragement.

    KeePass is very much a personal project of Dominik's, with a little help from others.
    Dominik's commitment and dedication are amazing for something which may, or may not provide a living for him.
    He has always argued consistently for his point of view, but has accepted change willingly.
    You may not agree with his idea of version control but it will be very well thought out and at least as valid as a public repository. Please accept his decision.

    cheers, Paul

     
1 2 > >> (Page 1 of 2)