{"thread":{"id":"14987","subject":"[RFC] Adding a challenge-response authentication method to git://","startedAt":"2008-08-13T16:26:44Z","lastAt":"2008-08-14T21:00:03Z","messageCount":18,"participants":["Stephen R. van den Berg","Petr Baudis","Shawn O. Pearce","David Brown","Andreas Ericsson","david@lang.hm"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"87071","messageId":"20080813162644.GC12200@cuci.nl","threadId":"14987","inReplyTo":null,"subject":"[RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-13T16:26:44Z","receivedAt":"2008-08-13T16:26:44Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"What are the opinions on adding a basic challenge-response type\nauthentication mechanism to the native git protocol?\nI.e. the authentication would be a simple one, which uses\nSHA1 (surprise ;-) to actually encrypt username/password/salt\nand authenticate the user.\n\nI'm willing to do the work, if there are no objections.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"And now for something *completely* different!\"\n"},{"id":"87072","messageId":"20080813163646.GO32184@machine.or.cz","threadId":"14987","inReplyTo":"20080813162644.GC12200@cuci.nl","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-13T16:36:46Z","receivedAt":"2008-08-13T16:36:46Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:\n> What are the opinions on adding a basic challenge-response type\n> authentication mechanism to the native git protocol?\n> I.e. the authentication would be a simple one, which uses\n> SHA1 (surprise ;-) to actually encrypt username/password/salt\n> and authenticate the user.\n> \n> I'm willing to do the work, if there are no objections.\n\nIn the past, such an idea was dismissed with desire not to reimplement\nsomething ssh already implemented, and much better than we would.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"87073","messageId":"20080813164038.GE3782@spearce.org","threadId":"14987","inReplyTo":"20080813162644.GC12200@cuci.nl","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-13T16:40:38Z","receivedAt":"2008-08-13T16:40:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Stephen R. van den Berg\" wrote:\n> What are the opinions on adding a basic challenge-response type\n> authentication mechanism to the native git protocol?\n> I.e. the authentication would be a simple one, which uses\n> SHA1 (surprise ;-) to actually encrypt username/password/salt\n> and authenticate the user.\n> \n> I'm willing to do the work, if there are no objections.\n\nLast time we talked about this we got off onto some tagent about\nusing GnuPG public keys to authenticate users, and then how we might\nstore the public keys in a keyring and log pushes (changes to refs)\nso that one could replicate the log on another server and come up\nwith the same result. Hence not just the current source code but\nalso the \"how we got here\" could be verified externally.\n\nUsername/password management is always ugly. Some admins will want\nyou to plug into PAM, others just want a flat file that is unique\nto the service, others want LDAP. And then you get into people\nwanting Kerberos support because they already have everything else\nin their domain supporting it. Tons of complexity for our project.\n\nIsn't there some authentication frontend that some IMAP servers\nuse to handle the authentication for them? I think last time\nI setup bincimap it used checkpassword. We might want to do the\nsame if we are going down this road...\n\n-- \nShawn.\n"},{"id":"87081","messageId":"20080813173757.GE12200@cuci.nl","threadId":"14987","inReplyTo":"20080813164038.GE3782@spearce.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-13T17:37:57Z","receivedAt":"2008-08-13T17:37:57Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>\"Stephen R. van den Berg\" wrote:\n>> What are the opinions on adding a basic challenge-response type\n>> authentication mechanism to the native git protocol?\n\n>> SHA1 (surprise ;-) to actually encrypt username/password/salt\n\n>Last time we talked about this we got off onto some tagent about\n>using GnuPG public keys to authenticate users, and then how we might\n...\n\nThat is the feature rich solution. For those there is ssh/webdav\nand possibly other setups.\n\n>Isn't there some authentication frontend that some IMAP servers\n>use to handle the authentication for them? I think last time\n\nThere is GSSAPI, which allows plugging in just about anything you like.\nNonetheless, for a lot of small projects, you have a relatively small\nnumber of developers (typically <32) which have commitrights on one or\nmore source trees in a central repository.\n\nIn order to aid them in setting up a simple accesslist, git would do\njust fine by simply offering a flat-file like list. Forcing those\nsetups to use anything more complicated makes adoption of git for those\nkind of projects unreasonably more complicated (IMO).\n\nThere are no promises for flexibility, security, whatsoever.\nThe only things I'm aiming for are:\na. Simplicity (need just git).\nb. No cleartext passwords over the wire.\nc. No encryption.\nd. Highest performance (native git protocol).\n\nAnyone needing more is referred to webdav/ssh and assorted solutions.\nThis minimises the dependencies on external libs, the only thing we need\nis a strong hash-function to implement (b); as it happens, we already\nhave SHA1..\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"And now for something *completely* different!\"\n"},{"id":"87085","messageId":"20080813180857.GH3782@spearce.org","threadId":"14987","inReplyTo":"20080813173757.GE12200@cuci.nl","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-13T18:08:57Z","receivedAt":"2008-08-13T18:08:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Stephen R. van den Berg\" wrote:\n> Shawn O. Pearce wrote:\n> >\"Stephen R. van den Berg\" wrote:\n> >> What are the opinions on adding a basic challenge-response type\n> >> authentication mechanism to the native git protocol?\n> \n> In order to aid them in setting up a simple accesslist, git would do\n> just fine by simply offering a flat-file like list. Forcing those\n> setups to use anything more complicated makes adoption of git for those\n> kind of projects unreasonably more complicated (IMO).\n\nWell, anytime you get into a flat-file access list you get into\nmanagement of that list. How do users change their own password?\nHow does an admin add/remove a user, or reset a password? What\ndefines an admin? Can you do these things remotely? Can you keep\nthe password encrypted on the remote side so an admin cannot see\na user's (common) password and maybe gain access to unrelated sites?\n\nIf you are going to keep it \"really simple\" you may be tempted to\nsay that all user additions/deletions/password changes should be\ndone by the admin directly editing the password list. At which\npoint it may actually be easier (and safer) for the admin to just\nhandle a GnuPG or SSH public key.\n\nThis is why we tend to rely on SSH. It neatly solves all of this\nfor us, and does it in a way that UNIX administrators are familiar\nwith managing.\n\nThis is also why the last discussion on this topic went down the road\nof using GnuPG to handle the authentication portion of the protocol.\nUnfortunately dealing with the server side keychain is a little\nbit more complex then I'd like it to be out of the box, and the\nclient side I think is lacking something as common as ssh-agent\nfor caching the decrypted key.\n\nI can see how it would be pretty simple to add authentication to\ngit-daemon based upon a shared secret, but such schemes always\ncause management problems on both sides.\n \n-- \nShawn.\n"},{"id":"87128","messageId":"20080814001029.GA14939@cuci.nl","threadId":"14987","inReplyTo":"20080813180857.GH3782@spearce.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-14T00:10:29Z","receivedAt":"2008-08-14T00:10:29Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>If you are going to keep it \"really simple\" you may be tempted to\n>say that all user additions/deletions/password changes should be\n>done by the admin directly editing the password list. At which\n\nCorrect.\n\n>point it may actually be easier (and safer) for the admin to just\n>handle a GnuPG or SSH public key.\n\nIf you want that, that is best handled in ssh.\n\n>This is why we tend to rely on SSH. It neatly solves all of this\n>for us, and does it in a way that UNIX administrators are familiar\n>with managing.\n\n>This is also why the last discussion on this topic went down the road\n>of using GnuPG to handle the authentication portion of the protocol.\n>Unfortunately dealing with the server side keychain is a little\n>bit more complex then I'd like it to be out of the box, and the\n>client side I think is lacking something as common as ssh-agent\n>for caching the decrypted key.\n\nI agree, which is why I don't want to put this complexity in git proper.\n\n>I can see how it would be pretty simple to add authentication to\n>git-daemon based upon a shared secret, but such schemes always\n>cause management problems on both sides.\n\nI'm not trying to solve all management problems, I'm just trying to\noffer a simple solution for the small-user-base-central-repository case\nwithout a lot of code-bloat on the git side.\nIf it doesn't fit ones needs, use ssh or something else; but it does\nhave its merits for the simple centralised setups.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"And now for something *completely* different!\"\n"},{"id":"87134","messageId":"20080814005723.GM3782@spearce.org","threadId":"14987","inReplyTo":"20080814001029.GA14939@cuci.nl","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-14T00:57:23Z","receivedAt":"2008-08-14T00:57:23Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Stephen R. van den Berg\" wrote:\n> I'm not trying to solve all management problems, I'm just trying to\n> offer a simple solution for the small-user-base-central-repository case\n> without a lot of code-bloat on the git side.\n> If it doesn't fit ones needs, use ssh or something else; but it does\n> have its merits for the simple centralised setups.\n\nOK, then my final two cents, and I'll shutup.\n\n- Add to git-daemon a new service command, \"git-authenticate-user\".\n- Clients request \"git-authenticate-user 'repository'\".\n- The auth_user routine:\n\tenters 'repository' ('ala upload-pack)\n\texecs \"git-authenticate-user .\"\n\n- git-authenticate-user:\n\tsend pkt-line challenge\n\trecv pkt-line username\n\trecv pkt-line SHA-1(username + password + challenge)\n\t\n\tread gitconfig for \"auth.passwordfile\"\n\tread passwordfile for entry $username\n\t\t(\"user:pass:upload-pack,receive-pack\")\n\tverify response\n\n\tsend pkt-line ok/fail\n\trecv pkt-line \"git-$service '.'\"\n\tcheck $service is allowed\n\texec git-$service .\n\n-- \nShawn.\n"},{"id":"87162","messageId":"20080814071328.GB9680@cuci.nl","threadId":"14987","inReplyTo":"20080814005723.GM3782@spearce.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-14T07:13:28Z","receivedAt":"2008-08-14T07:13:28Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>\"Stephen R. van den Berg\" wrote:\n>> I'm not trying to solve all management problems, I'm just trying to\n>> offer a simple solution for the small-user-base-central-repository case\n>> without a lot of code-bloat on the git side.\n>> If it doesn't fit ones needs, use ssh or something else; but it does\n>> have its merits for the simple centralised setups.\n\n>- Add to git-daemon a new service command, \"git-authenticate-user\".\n[...implementation suggestion omitted...]\n\nSounds like a plan. I'll see if it is workable.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"Hold still, while I inject you with SQL.\"\n"},{"id":"87165","messageId":"20080814074805.GA21577@linode.davidb.org","threadId":"14987","inReplyTo":"20080813163646.GO32184@machine.or.cz","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-08-14T07:48:05Z","receivedAt":"2008-08-14T07:48:05Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Wed, Aug 13, 2008 at 06:36:46PM +0200, Petr Baudis wrote:\n>On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:\n>> What are the opinions on adding a basic challenge-response type\n>> authentication mechanism to the native git protocol?\n>> I.e. the authentication would be a simple one, which uses\n>> SHA1 (surprise ;-) to actually encrypt username/password/salt\n>> and authenticate the user.\n>\n>In the past, such an idea was dismissed with desire not to reimplement\n>something ssh already implemented, and much better than we would.\n\nThe problem is that ssh ties you in very closely with the ability to\nlog into the machine. It's also hard to limit what ssh allows while\nstill allowing some users more priveleges.\n\nBut, this problem comes up with other protocols that use ssh for\nauthentication as well, so perhaps the solution is to fix the problems\nwith ssh to allow it to more securely allow non-login services.\n\nDavid\n"},{"id":"87166","messageId":"20080814082345.GQ10151@machine.or.cz","threadId":"14987","inReplyTo":"20080814074805.GA21577@linode.davidb.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-14T08:23:45Z","receivedAt":"2008-08-14T08:23:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 14, 2008 at 12:48:05AM -0700, David Brown wrote:\n> On Wed, Aug 13, 2008 at 06:36:46PM +0200, Petr Baudis wrote:\n>> On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:\n>>> What are the opinions on adding a basic challenge-response type\n>>> authentication mechanism to the native git protocol?\n>>> I.e. the authentication would be a simple one, which uses\n>>> SHA1 (surprise ;-) to actually encrypt username/password/salt\n>>> and authenticate the user.\n>>\n>> In the past, such an idea was dismissed with desire not to reimplement\n>> something ssh already implemented, and much better than we would.\n>\n> The problem is that ssh ties you in very closely with the ability to\n> log into the machine. It's also hard to limit what ssh allows while\n> still allowing some users more priveleges.\n\nCan you elaborate, in light of git-shell and Gitosis? What's the\nproblem?\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"87171","messageId":"48A3F7AA.8070001@op5.se","threadId":"14987","inReplyTo":"20080814005723.GM3782@spearce.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-14T09:15:22Z","receivedAt":"2008-08-14T09:15:22Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> \"Stephen R. van den Berg\" wrote:\n>> I'm not trying to solve all management problems, I'm just trying to\n>> offer a simple solution for the small-user-base-central-repository case\n>> without a lot of code-bloat on the git side.\n>> If it doesn't fit ones needs, use ssh or something else; but it does\n>> have its merits for the simple centralised setups.\n> \n> OK, then my final two cents, and I'll shutup.\n> \n> - Add to git-daemon a new service command, \"git-authenticate-user\".\n> - Clients request \"git-authenticate-user 'repository'\".\n> - The auth_user routine:\n> \tenters 'repository' ('ala upload-pack)\n> \texecs \"git-authenticate-user .\"\n> \n> - git-authenticate-user:\n> \tsend pkt-line challenge\n> \trecv pkt-line username\n> \trecv pkt-line SHA-1(username + password + challenge)\n> \t\n> \tread gitconfig for \"auth.passwordfile\"\n> \tread passwordfile for entry $username\n> \t\t(\"user:pass:upload-pack,receive-pack\")\n> \tverify response\n> \n> \tsend pkt-line ok/fail\n> \trecv pkt-line \"git-$service '.'\"\n> \tcheck $service is allowed\n> \texec git-$service .\n> \n\nI'd do it like this instead:\n\ndaemon: auth_user = dlsym(dlopen(\"auth-module.so\", RTLD_NOW), \"authenticat\");\nclient: \"git-authenticate action 'repository'\"\ndaemon: send pkt-line challenge\nclient: send pkt-line username\nclient: send pkt-line SHA1(username + password + challenge)\ndaemon: if (auth_user(repository, action, username, password, struct sockaddr_in *inbound))\n allow_connection();\n\nThis approach has several nifty benefits:\n* The otherwise duplicated code (for different auth schemes) is\n done only once (in the git daemon).\n* If the git daemon has no authentication module loaded, we might\n as well not bother sending any challenge and just pretend we do\n not know about the authentication scheme.\n* Any kind of authentication scheme can be supported without changing\n the core code. If the authentication module does something wrong,\n one can continue to serve read-only requests by simply unloading\n the module.\n* Modules is a great way for newcomers to get started contributing to\n git so it's a nice way of getting more contributors/sub-maintainers.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"87172","messageId":"20080814095137.GF9680@cuci.nl","threadId":"14987","inReplyTo":"48A3F7AA.8070001@op5.se","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-14T09:51:37Z","receivedAt":"2008-08-14T09:51:37Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n>I'd do it like this instead:\n\n>daemon: auth_user = dlsym(dlopen(\"auth-module.so\", RTLD_NOW), \n>\"authenticat\");\n\n>This approach has several nifty benefits:\n>* The otherwise duplicated code (for different auth schemes) is\n> done only once (in the git daemon).\n\nI'd prefer that to be in a separate program, instead of git-daemon\nproper.\n\n>* If the git daemon has no authentication module loaded, we might\n> as well not bother sending any challenge and just pretend we do\n> not know about the authentication scheme.\n\nLoading modules is highly fragile across different OSes, so it's not\nreally recommended at all.\n\n>* Modules is a great way for newcomers to get started contributing to\n> git so it's a nice way of getting more contributors/sub-maintainers.\n\nIf by \"modules\" you mean dynamically loaded libraries, then I\nwholeheartedly disagree.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"Hold still, while I inject you with SQL.\"\n"},{"id":"87184","messageId":"20080814110739.GI9680@cuci.nl","threadId":"14987","inReplyTo":"20080814082345.GQ10151@machine.or.cz","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-14T11:07:39Z","receivedAt":"2008-08-14T11:07:39Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Petr Baudis wrote:\n>On Thu, Aug 14, 2008 at 12:48:05AM -0700, David Brown wrote:\n>> The problem is that ssh ties you in very closely with the ability to\n>> log into the machine. It's also hard to limit what ssh allows while\n>> still allowing some users more priveleges.\n\n>Can you elaborate, in light of git-shell and Gitosis? What's the\n>problem?\n\nWell, I looked into gitosis, and it solves part of the problem, it has a\nfew downsides though:\n\n- It depends on Python for no particular reason (it might as well have\n been built using shellscripts only, or if need be Perl, since git\n already uses that); yet any extra dependency is creating an extra\n hurdle for portability and adoption.\n- It does authentication magic without properly documenting why it does\n it properly.\n- It explicitly warns that it needs PATH and PYTHON_PATH magic and that\n using it without setting those up has not been tested; this does not\n inspire confidence that the security of the solution is airtight.\n\nOther than that, gitosis looks fairly good if you want to use public\nkeys.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"Hold still, while I inject you with SQL.\"\n"},{"id":"87185","messageId":"20080814113901.GR10151@machine.or.cz","threadId":"14987","inReplyTo":"20080814110739.GI9680@cuci.nl","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-14T11:39:01Z","receivedAt":"2008-08-14T11:39:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 14, 2008 at 01:07:39PM +0200, Stephen R. van den Berg wrote:\n> Well, I looked into gitosis, and it solves part of the problem, it has a\n> few downsides though:\n> \n> - It depends on Python for no particular reason (it might as well have\n> been built using shellscripts only, or if need be Perl, since git\n> already uses that); yet any extra dependency is creating an extra\n> hurdle for portability and adoption.\n\nIs this concern really any kind of practical one? To me it appears that\nPython and Perl are both so extremely wide-spread that this might be\nissue only on embedded systems, exotic systems with very low proportion\nof git users, and users with strong ideological opinions about the\nsystem (probably low proportion of git users too).\n\n> - It does authentication magic without properly documenting why it does\n> it properly.\n> - It explicitly warns that it needs PATH and PYTHON_PATH magic and that\n> using it without setting those up has not been tested; this does not\n> inspire confidence that the security of the solution is airtight.\n> \n> Other than that, gitosis looks fairly good if you want to use public\n> keys.\n\nThis doesn't seem to be convincing reason for _reimplementing_ the\nsolution. (Of course, I don't prevent you from doing that, I'm just\nwondering about the feasibility.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"87186","messageId":"20080814121412.GA25791@cuci.nl","threadId":"14987","inReplyTo":"20080814113901.GR10151@machine.or.cz","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-08-14T12:14:12Z","receivedAt":"2008-08-14T12:14:12Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Petr Baudis wrote:\n>On Thu, Aug 14, 2008 at 01:07:39PM +0200, Stephen R. van den Berg wrote:\n>> Well, I looked into gitosis, and it solves part of the problem, it has a\n>> few downsides though:\n\n>> - It depends on Python for no particular reason (it might as well have\n>> been built using shellscripts only, or if need be Perl, since git\n>> already uses that); yet any extra dependency is creating an extra\n>> hurdle for portability and adoption.\n\n>Is this concern really any kind of practical one? To me it appears that\n>Python and Perl are both so extremely wide-spread that this might be\n>issue only on embedded systems, exotic systems with very low proportion\n>of git users, and users with strong ideological opinions about the\n>system (probably low proportion of git users too).\n\nI agree that in general it shouldn't be a major problem to get it on the\nsystems you want to use it on; but it does increase the difficulty of\nauditing the solution before deploying it.\n\n>> Other than that, gitosis looks fairly good if you want to use public\n>> keys.\n\n>This doesn't seem to be convincing reason for _reimplementing_ the\n>solution. (Of course, I don't prevent you from doing that, I'm just\n>wondering about the feasibility.)\n\nI'm not going to reimplement gitosis. I'm going to do *less* than\ngitosis for situations where gitosis is undesirable (for whatever\nreason, not necessarily the critisisms I mentioned before).\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"Hold still, while I inject you with SQL.\"\n"},{"id":"87205","messageId":"alpine.DEB.1.10.0808141018220.13400@asgard.lang.hm","threadId":"14987","inReplyTo":"20080813164038.GE3782@spearce.org","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-08-14T17:18:38Z","receivedAt":"2008-08-14T17:18:38Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 13 Aug 2008, Shawn O. Pearce wrote:\n\n> Isn't there some authentication frontend that some IMAP servers\n> use to handle the authentication for them? I think last time\n> I setup bincimap it used checkpassword. We might want to do the\n> same if we are going down this road...\n\nare you thinking of SASL?\n\nDavid Lang\n"},{"id":"87208","messageId":"alpine.DEB.1.10.0808141021210.13400@asgard.lang.hm","threadId":"14987","inReplyTo":"48A3F7AA.8070001@op5.se","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-08-14T17:24:37Z","receivedAt":"2008-08-14T17:24:37Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 14 Aug 2008, Andreas Ericsson wrote:\n\n> I'd do it like this instead:\n>\n> daemon: auth_user = dlsym(dlopen(\"auth-module.so\", RTLD_NOW), \"authenticat\");\n> client: \"git-authenticate action 'repository'\"\n> daemon: send pkt-line challenge\n> client: send pkt-line username\n> client: send pkt-line SHA1(username + password + challenge)\n> daemon: if (auth_user(repository, action, username, password, struct \n> sockaddr_in *inbound))\n> allow_connection();\n>\n> This approach has several nifty benefits:\n> * The otherwise duplicated code (for different auth schemes) is\n> done only once (in the git daemon).\n> * If the git daemon has no authentication module loaded, we might\n> as well not bother sending any challenge and just pretend we do\n> not know about the authentication scheme.\n> * Any kind of authentication scheme can be supported without changing\n> the core code. If the authentication module does something wrong,\n> one can continue to serve read-only requests by simply unloading\n> the module.\n> * Modules is a great way for newcomers to get started contributing to\n> git so it's a nice way of getting more contributors/sub-maintainers.\n\nif you're going to do modules, you should give the module the connection \nuntil it's done so that different types of authentication can be \nimplemented by the module.\n\nDavid Lang\n"},{"id":"87232","messageId":"20080814210003.GQ3782@spearce.org","threadId":"14987","inReplyTo":"alpine.DEB.1.10.0808141018220.13400@asgard.lang.hm","subject":"Re: [RFC] Adding a challenge-response authentication method to git://","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-14T21:00:03Z","receivedAt":"2008-08-14T21:00:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"david@lang.hm wrote:\n> On Wed, 13 Aug 2008, Shawn O. Pearce wrote:\n>\n>> Isn't there some authentication frontend that some IMAP servers\n>> use to handle the authentication for them? I think last time\n>> I setup bincimap it used checkpassword. We might want to do the\n>> same if we are going down this road...\n>\n> are you thinking of SASL?\n\nMaybe I was. But I think I was thinking about DJB's checkpassword\ntool. There are several tools that implement the same calling\nconventions, some of which link to PAM or an LDAP database, etc.\nPlus its fairly easy to create your own if you really needed a\ncustom solution. You just have to be able to read fd 3. :)\n\n-- \nShawn.\n"}]}