This discussion kicked off on the wrong list, so since I started
it, I've concatenated the posts.
Intro:
--
I used the --password option in a commit and then found that the
process with my password in full view hung around for an entire week
and could be seen by anyone with access to the same
Ben wrote:
> Rewriting the array isn't seen by the kernel. At least when I initially
wrote
> that example I tried just setting argv[++i] = "" and the ps
output
> didn't change.
Could that be because of the libtool svn-lt script that sits in the middle?
Because in gdb it does change, but not in p
On 7/3/14 4:23 PM, Gabriela Gibson wrote:
> Could that be because of the libtool svn-lt script that sits in the middle?
> Because in gdb it does change, but not in ps.
No because I wasn't even doing anything with Subversion yet let alone libtool.
It was just a very basic C program with nothing mo
Oh, I was playing about with this earlier, but didn't get all that far:
I go this far in svn.c (has breakpoint marker in it)
[[[
int
main(int argc, char **argv)
{
apr_pool_t *pool;
int exit_code = EXIT_SUCCESS;
svn_error_t *err;
const char **argv_org;
/* Initiali
I also looked at the C90 standard because I thought maybe they defined argv
as immutable (since it should not complain about being const with this type
of main declaration I think) and this is what is says:
"The parameters argc and argv and the strings pointed to by the argv array
shall
be modifia
On 7/3/14 4:50 PM, Gabriela Gibson wrote:> it compiles and runs and in gdb the
vars do change, but the compiler isn't happy:
> subversion/svn/svn.c: In function 'main':
>
> subversion/svn/svn.c:3048:23: warning: assignment discards 'const' qualifier
> from pointer target type [enable\
> d by defaul
On 07/04/14 04:47, Gabriela Gibson wrote:
This is a summary of Ben's reply:
Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700:
> 1) Remove the option.
> 2) Redact the password in the argv after starting up and finding the
> bits to redact.
3) Allow the password to be supplied over std
On 7/3/14 9:10 PM, Martin Furter wrote:
> 3) Allow the password to be supplied over stdin using the special value "-".
>
> Nobody will see the password. The only leak is that a password has been
> supplied using stdin. An attacker will have to convince the calling
> application
> to run something
What if we leave the current --password as is (for convenience) and just
add an optional, secondary password mechanism for those admins who want to
be doubly sure?
On Fri, Jul 4, 2014 at 7:00 AM, Ben Reser wrote:
> On 7/3/14 9:10 PM, Martin Furter wrote:
> > 3) Allow the password to be supplie
On 04.07.2014 02:14, Gabriela Gibson wrote:
> I also looked at the C90 standard because I thought maybe they defined
> argv as immutable (since it should not complain about being const with
> this type of main declaration I think) and this is what is says:
>
> "The parameters argc and argv and the
On 04.07.2014 04:34, Ben Reser wrote:
> On 7/3/14 4:50 PM, Gabriela Gibson wrote:> it compiles and runs and in gdb the
> vars do change, but the compiler isn't happy:
>> subversion/svn/svn.c: In function 'main':
>>
>> subversion/svn/svn.c:3048:23: warning: assignment discards 'const' qualifier
>> f
On Fri, Jul 4, 2014 at 8:46 AM, Branko Čibej wrote:
> On 04.07.2014 02:14, Gabriela Gibson wrote:
>
> I also looked at the C90 standard because I thought maybe they defined
> argv as immutable (since it should not complain about being const with this
> type of main declaration I think) and this
Hi,
Von: Gabriela Gibson [mailto:gabriela.gib...@gmail.com]
> This discussion kicked off on the wrong list, so since I started
> it, I've concatenated the posts.
>
> Intro:
> --
>
> I used the --password option in a commit and then found that the
> process with my password in full view hun
Hi,
> [Long discussion snipped to protect the innocent]
>
> As far as I know, an environment variable could be used as an alternative. It
> can be set by shell scripts and the python test harness locally (only
> affecting the started svn sub process), and on most operating systems, other
> non-ad
Ben Reser writes:
> I don't think the C standards specify this sort of behavior but something has
> to be shared between the kernel and the process in order to allow this
> modification.
sendmail is known for changing its ps line. There is a python module
that demonstrates various methods:
htt
Markus Schaber wrote:
> Julian Foad wrote:
>> "specify a password ARG (insecure: on many systems,
>> other users can read the command-line arguments)"
>
> I fully agree with your concerns about vague warnings. But in my eyes,
> it is also important to point out the alternatives, so that the us
I was about to commit Ben's suggestion of changing the --password help text to
"specify a password ARG (this usually is not secure)"
as a first step that would be useful on its own regardless whether we do
something more.
But then I thought about how users (myself included) tend to ignore war
Hi, Julian,
> Von: Julian Foad [mailto:julianf...@btopenworld.com]
> I was about to commit Ben's suggestion of changing the --password help text
> to
>
> "specify a password ARG (this usually is not secure)"
>
> as a first step that would be useful on its own regardless whether we do
> somethi
18 matches
Mail list logo
