In-Reply-To<[email protected]>
References: <[email protected]>
<[email protected]>
On Tue, 29 Dec 2015 23:03:34 +0800, Matt Johnston wrote:
> On Mon, Dec 07, 2015 at 10:42:59PM -0000, Michael Witten wrote:
>> User names have hitherto been handled neither consistently nor well; this
>> series alleviates at least some of the issues.
>>
>> Fear not the long patch series!
>>
>> Most commits involve a fairly small number of changes; while I could have
>> consolidated these changes into fewer commits, I think the series as a whole
>> provides a better narration for what's going.
>>
>> Besides a few small improvements along the way, the main thrust is:
>>
>> * Removing user-name handling from `scp' (in favor of using the
>> handling that is already present in `dropbear'/`dbclient').
>>
>> * Lazily looking up the current user's name.
>>
>> * Removing unused code.
>>
>> Overall, 7 files were changed, with 37 insertions(+) and 158 deletions(-):
>>
>> cli-main.c | 2 +-
>> cli-runopts.c | 32 ++++++--------
>> common-session.c | 1 +
>> runopts.h | 2 +-
>> scp.c | 125
>> ++++++++++---------------------------------------------
>> scpmisc.c | 31 +-------------
>> scpmisc.h | 2 -
>>
>> This is the series:
>>
>> [01] scp: Insert comma into stderr message
>> [02] scp: Have `fatal()' append a newline to the message
>> [03] scp: only pass `-v' when DEBUG_TRACE is set
>> [04] scp: `-l%s' -> `-l %s'
>> [05] scp: const/static correctness improvements
>> [06] scp: Introduce `get_user_name()'
>> [07] scp: Use "unknown" when the user name cannot be retrieved
>> [08] scp: style: simplify code by using a tertiary operator
>> [09] scp: Use `get_user_name()' more often
>> [10] scp: Simplify code now that the user name is never `NULL'
>> [11] scp: Remove parsing of `[user@]host'
>> [12] scp: Remove unused functions
>> [13] scp: Remove `replacearg()'
>> [14] runopts: Mark `*cli_runopts.own_user' as `const'
>> [15] runopts: There's no reason to make a duplicate of "unknown"
>> [16] runopts: Re-introduce the `get_user_name()' function from `scp'
>> development
>>
>> Lastly, for convenience in reviewing the changes, here is the overall patch:
>>
>> [ ... ]
>
> Hi Michael,
>
> I think the general change of these patches makes sense
> (avoiding failure when a local user doesn't exist) but it
> needs to be more minimal. scp comes straight from OpenSSH
> with some small changes for uClinux etc. I've tried to
> avoid additional changes since it really needs updating to a
> more recent OpenSSH - the more changes, the larger that work
> is. Upstreaming it might be an option.
>
> Cheers,
> Matt
Well, even if I go through the trouble of interfacing with this
other community (OpenSSH), and thereby successfully introduce
these changes 'upstream', it sounds like there's still going to
be a lot of work to get the result merged 'downstream' as
part of the project that I actually [and, yet, only marginally]
care about (Dropbear SSH).
This seems like it's going to be a waste of my time, and I've
already spent a not-insignificant amount of time on this.
My instinct is that we should view Dropbear's copies as being
what they, in fact, are: forks with their own history and
purpose.
Yet, if that view is undesirable, then let's get this set
straight now and for the rest of time:
* Let's identify all the files that are viewed as being merely
patched copies of 'upstream' files.
* Let's segregate them obviously, and make clear notes (for the
benefit of others) that all substantive changes should be made
upstream.
+ Most portably, these files could be refactored into a
subdirectory named 'upstream' or 'third-party'.
It would be possible to account for DropBear-specific patches
either explicitly (by applying them at build-time), or implicitly
(by placing them in a specific branch that is merged with the main
line of history via a non-fastforward merge commit).
+ Alternatively, these files could be included in at least one git
submodule (or the mercurial equivalent); this submodule
could then track the patches explicitly, and provide a focus for
discussing Dropbear-specific patches and upstream synchronization.
* Let's bring those 'upstream' copies up-to-date.
Only after this effort, will it make sense to me to try to introduce
my patches upstream in order to have them merged downstream.
Sincerely,
Michael Witten
