On Wed, Oct 20, 2010 at 4:30 PM, David Brodbeck wrote:
> If I have root access to the filesystem, it doesn't matter what SSH
> does to try to encrypt the password...
Typo. s/SSH/SVN/
--
David Brodbeck
System Administrator, Linguistics
University of Washington
On Fri, Oct 15, 2010 at 7:01 PM, Nico Kadel-Garcia wrote:
> No. system_auth is still the NFS standard for internal use in both
> academic and professional environments. auth_dh has uses, but it
> doesn't help against any machine with allocated or cracked local root
> access. This isn't your "local
On Mon, Oct 18, 2010 at 12:56 AM, Stephen Connolly
wrote:
> It would be trivial to fork svn to lie and report that it only stored
> passwords encrypted, stick that forked client on my machine and hey
> presto, away I go storing my password in plaintext.
If someone is *that* determined to shoot th
Johan Corveleyn wrote on Tue, Oct 19, 2010 at 11:18:20 +0200:
> Maybe there is already some functionality present for protocol/feature
> negotiation, I don't know ...
All RA layers have a 'capability negotiation' support:
svn_ra_has_capability() allows the client to ask the server what it
supports
On 19 October 2010 10:18, Johan Corveleyn wrote:
> On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly
> wrote:
>> Exposing the feature would not in an of itself force the client to use
>> the keyring, but it would allow the server to have a start-commit hook
>> that blocked a commit if the user ha
On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly
wrote:
> Exposing the feature would not in an of itself force the client to use
> the keyring, but it would allow the server to have a start-commit hook
> that blocked a commit if the user had plaintext password storage
> enabled...
Just keep in m
On 19 October 2010 02:17, Nico Kadel-Garcia wrote:
> On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
> wrote:
>
>> Add a capability called "keyringenabled" to Subversion and now Nico
>> will probably be much happier... but of course he doesn't trust his
>> users so he cannot trust that they rep
On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
wrote:
> Add a capability called "keyringenabled" to Subversion and now Nico
> will probably be much happier... but of course he doesn't trust his
> users so he cannot trust that they report "keyringenabled"
> correctly... but he might be pragmati
On 17 October 2010 08:52, Alan Barrett wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use on the
Nico Kadel-Garcia wrote on Sun, Oct 17, 2010 at 08:41:51 -0400:
> On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett wrote:
> > On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> >> > What he really wants is an alternate-universe Subversion which never
> >> > had the plaintext password storage feature in
On Sun, Oct 17, 2010 at 03:14:09PM +0200, Stefan Sperling wrote:
> The gpg-agent password store will be optional and behave just like
> the gnome-keyring and kwallet stores.
Just FYI, the current implementation of this feature doesn't seem
to be usable: http://svn.haxx.se/dev/archive-2010-10/0286.
On Sun, Oct 17, 2010 at 12:14:12AM -0400, Nico Kadel-Garcia wrote:
> On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling wrote:
> > I share Nico's concerns, and when I did (successfully) try to get the
> > behaviour changed, the community was OK with adding a prompt, but not
> > with dropping the fe
On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use
On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> > What he really wants is an alternate-universe Subversion which never
> > had the plaintext password storage feature in the first place.
>
> I'd settle for being able to block that local use on the server side:
OK, so you want a feature in which th
On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling wrote:
> It should be noted that, in our community, contributing towards such
> goals will also require compromise. Which people concerned about security
> are rarely willing to make ("good enough" isn't good enough, it needs to
> be as good and s
On Sat, Oct 16, 2010 at 10:54 AM, Les Mikesell wrote:
> On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote:
>
>>
>> And I'd like a pony. More seriously, "doesn't introduce additional
>> setup requirements" is an amazingly high bar for real world security.
>> The small vulnerabilities stack up to a far t
On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote:
And I'd like a pony. More seriously, "doesn't introduce additional
setup requirements" is an amazingly high bar for real world security.
The small vulnerabilities stack up to a far too common, vulnerable set
up that exists world wide.
If you are w
On Sat, Oct 16, 2010 at 10:43:01AM +0200, Erik Huelsmann wrote:
> Hi Nico,
>
> > I'd love to see this deployed, and love to see the protocol updated
> > enough to block the use of the older, less secure clients. But 1.7 has
> > already blown well past its release date of "this summer. If it's not
On Sat, Oct 16, 2010 at 4:43 AM, Erik Huelsmann wrote:
> Hi Nico,
>
>> I'd love to see this deployed, and love to see the protocol updated
>> enough to block the use of the older, less secure clients. But 1.7 has
>> already blown well past its release date of "this summer. If it's not
>> in featur
Hi Nico,
> I'd love to see this deployed, and love to see the protocol updated
> enough to block the use of the older, less secure clients. But 1.7 has
> already blown well past its release date of "this summer. If it's not
> in feature freeze, I'll be pleasantly surprised to see such a feature.
>
On Thu, Oct 14, 2010 at 2:28 PM, Stefan Sperling wrote:
> On Thu, Oct 14, 2010 at 10:56:35AM -0700, David Brodbeck wrote:
>> On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia wrote:
>> > Think I'm kidding? Walk into any university environment: plug in a
>> > live Linux CD. Run an "nmap" scan for
On Thu, Oct 14, 2010 at 4:58 PM, David Brodbeck wrote:
> On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling wrote:
>> As of 1.6, Subversion asks the user before saving passwords in
>> plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet
>> as password stores.
>
> Yup. There ar
On Thu, Oct 14, 2010 at 2:22 PM, Stefan Sperling wrote:
> I hope the work-in-progress gpg-agent support I mentioned will fill that gap.
> Would using gpg-agent work for you?
Quite likely. I haven't really played with gpg-agent, but I don't
know of any reason it shouldn't work.
--
David Brodbe
On Thu, Oct 14, 2010 at 01:58:19PM -0700, David Brodbeck wrote:
> On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling wrote:
> > As of 1.6, Subversion asks the user before saving passwords in
> > plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet
> > as password stores.
>
> Yu
On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling wrote:
> As of 1.6, Subversion asks the user before saving passwords in
> plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet
> as password stores.
Yup. There are, as noted, unfortunately a lot of hassles involved
with those
On Thu, Oct 14, 2010 at 10:56:35AM -0700, David Brodbeck wrote:
> On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia wrote:
> > Second, many working environments in the UNIX world rely on NFS based
> > home directoies, to share working environments and configurations
> > across a variety of machine
On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia wrote:
> Second, many working environments in the UNIX world rely on NFS based
> home directoies, to share working environments and configurations
> across a variety of machines. In such environments, *any* host that
> can be leveraged to local roo
Le 10/10/2010 22:17, Nico Kadel-Garcia a écrit :
On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia wrote:
Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
svn+ssh is the most secure, but it conflcts with your desire for LDAP
access. The SSH keys normally live under a single user's account, the
On Sun, Oct 10, 2010 at 4:26 PM, Les Mikesell wrote:
> On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote:
>>> If they didn't, it would be impossible to do automated commands. There
>>> are
>>> times when you have to choose between trusting the OS to protect your
>>> files
>>> (which is, after all, on
Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
svn+ssh is the most secure, but it conflcts with your desire for LDAP
access. The SSH keys normally live under a single user's account, the
user who owns the repository, who hsould have a locked password. You
see why this conflicts with LDAP based
Le 09/10/2010 15:39, Nico Kadel-Garcia a écrit :
On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer wrote:
The client should be able to store the credentials if you have it set up to do
so. On windows/mac it is encrypted with OS included libraries. For Linux you
need to set up gnome keyring or
On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote:
On Sat, Oct 9, 2010 at 2:05 PM, Les Mikesell wrote:
On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
unprotected keys to be stored locally, with no special command line
arguments or spe
On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia wrote:
> Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
>>
>> svn+ssh is the most secure, but it conflcts with your desire for LDAP
>> access. The SSH keys normally live under a single user's account, the
>> user who owns the repository, who hsould
On Sat, Oct 9, 2010 at 2:05 PM, Les Mikesell wrote:
> On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
>> Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
>> unprotected keys to be stored locally, with no special command line
>> arguments or special settings, and impossible to compile
On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
On Sat, Oct 9, 2010 at 11:06 AM, Les Mikesell wrote:
On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
Look, Subversion inherited its practice of storing password in
cleartext from its ancestor, CVS. It's been an uphill battle ever
since to wallpaper o
On Sat, Oct 9, 2010 at 11:06 AM, Les Mikesell wrote:
> On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
>>
>> Look, Subversion inherited its practice of storing password in
>> cleartext from its ancestor, CVS. It's been an uphill battle ever
>> since to wallpaper over the practice: there are enough la
On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
Look, Subversion inherited its practice of storing password in
cleartext from its ancestor, CVS. It's been an uphill battle ever
since to wallpaper over the practice: there are enough layers of
wallpaper, finally, that it's almost thick enough to be a
I did just misspell "sudo" and tell the same story twice about opening
up people's email with their stored passwords, didn't I?
Remind me to re-edit *twice* before sending a rant.
On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer wrote:
> The client should be able to store the credentials if you have it set up to
> do so. On windows/mac it is encrypted with OS included libraries. For Linux
> you need to set up gnome keyring or kde-wallet.
>
> http://svnbook.red-bean.com/nightl
> Le 08/10/2010 15:59, Bob Archer a écrit :
> >> Now, is collabnet solution able to serve tradition unix shell
> >> comand
> >> line clients ? is there a svnserve server behind it or is apache
> >> able to
> >> serve those clients using svn protocol too ?
> > BTW: If you have http(s) access you d
Le 08/10/2010 15:59, Bob Archer a écrit :
Now, is collabnet solution able to serve tradition unix shell
comand
line clients ? is there a svnserve server behind it or is apache
able to
serve those clients using svn protocol too ?
BTW: If you have http(s) access you don't also need svn protocol.
> Now, is collabnet solution able to serve tradition unix shell
> comand
> line clients ? is there a svnserve server behind it or is apache
> able to
> serve those clients using svn protocol too ?
BTW: If you have http(s) access you don't also need svn protocol. The svn
command line client suppor
Le 08/10/2010 14:54, Andy Levy a écrit :
On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia wrote:
Also note: both the 'svn' and 'http' access send the passwords ovder
the network in clear text. There are ways around this (such as SSH or
SSL tunneling), but they're pesky to set up. Fortunately, "
On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia wrote:
> Also note: both the 'svn' and 'http' access send the passwords ovder
> the network in clear text. There are ways around this (such as SSH or
> SSL tunneling), but they're pesky to set up. Fortunately, "https"
> already has that built in.
HT
On Fri, Oct 8, 2010 at 2:09 PM, Nico Kadel-Garcia wrote:
> On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia
> wrote:
>> Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
>>> Unless you can guarantee that they will not use Linux or UNIX based
>>> clients, don't even consider this. The problem is th
On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia
wrote:
> Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
>>
>> On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
>> wrote:
>>>
>>> Le 06/10/2010 17:06, Siva Kumar a écrit :
>
> I need to provide svn service to many small groups of student
Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
wrote:
Le 06/10/2010 17:06, Siva Kumar a écrit :
I need to provide svn service to many small groups of students.
I'am looking for a tool that would help industrialize managment of
repositories
On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
wrote:
> Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>
>>> I need to provide svn service to many small groups of students.
>>> I'am looking for a tool that would help industrialize managment of
>>> repositories.
>>> I don't want to issue hundreds o
> Le 06/10/2010 17:06, Siva Kumar a écrit :
> >> I need to provide svn service to many small groups of students.
> >> I'am looking for a tool that would help industrialize managment
> of
> >> repositories.
> >> I don't want to issue hundreds of "svn create", "vi authz" ,
> edit ssh keys
> >> for
Le 06/10/2010 17:06, Siva Kumar a écrit :
I need to provide svn service to many small groups of students.
I'am looking for a tool that would help industrialize managment of
repositories.
I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
for svn+ssh access etc ...
Are the
> I need to provide svn service to many small groups of students.
> I'am looking for a tool that would help industrialize managment of
> repositories.
> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
> for svn+ssh access etc ...
> Are there such tools already existing
hello,
I need to provide svn service to many small groups of students.
I'am looking for a tool that would help industrialize managment of
repositories.
I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
keys for svn+ssh access etc ...
Are there such tools already existing
52 matches
Mail list logo
