[mosh-devel] Introduction: Wolfgang E. Sanyer

Fri Jan 28 16:43:59 EST 2022

El vie, 28 ene 2022 a la(s) 16:13, Alex Chernyakhovsky (achernya at mit.edu)
escribió:

>
>
> On Fri, Jan 28, 2022 at 3:37 PM Wolfgang E. Sanyer <
> wolfgangesanyer at gmail.com> wrote:
>
>>
>>
>> El jue, 27 ene 2022 a la(s) 13:38, Keith Winstein (keithw at mit.edu)
>> escribió:
>>
>>> On Thu, Jan 27, 2022 at 3:49 AM Wolfgang E. Sanyer <
>>> wolfgangesanyer at gmail.com> wrote:
>>>
>>>> Keith,
>>>>
>>>> Thanks for the welcome, and thanks for your detailed and thoughtful
>>>> response!
>>>>
>>>> I'm very thankful for the outline you've put together, as it gives me a
>>>> clear strategy for what needs to be done to move forward.
>>>>
>>>
>>> Awesome. And (I should have said this before), but I'd be happy to put a
>>> regular videochat on the calendar if that would be helpful to you and
>>> Alex/Ben/Quentin in keeping track of blockers and giving advice. That's not
>>> normally how we do things in FLOSS and maybe it's not necessary here, but
>>> if 30 minutes synchronous every week or two would be helpful, I'd be happy
>>> to commit to that.
>>>
>>
>> I probably prefer to keep communications on the mailing list or on a
>> github issue/PR honestly.
>>
>>
>>> To answer your question "Are you interested in....or...any other part of
>>>> this process", my answer is "yes I'm interested in all of it".
>>>>
>>>> Let me summarize your email just to be sure I'm not missing anything:
>>>>
>>>> - Document the release process
>>>>     - this includes starting with a release candidate to allow for
>>>> broader testing
>>>> - "look over"/"scrutinize" any commits since the last release
>>>>     - I could use some clarity here: are you suggesting that I perform
>>>> this in isolation? Or use some github feature to perform a more formal code
>>>> review?
>>>>
>>>
>>> I think I would like you and Alex to tell me (and the rest of the
>>> community), "Yes, we've looked over the recent commits, it looks good to
>>> us, we don't see any buffer overflows, and [most importantly] we understand
>>> them well enough to say that we're going to stick around and be here to fix
>>> what needs fixing if the shit hits the fan after the release happens."
>>>
>>> What I didn't want to do was step back in after years away and cut a
>>> release lazily that has a bunch of cgull commits that I didn't review,
>>> don't understand, and hadn't put the effort into scrutinizing -- that
>>> seemed like a recipe for how we'd get our first real security hole.
>>>
>>
>> I guess I'm still a bit confused about this - what's the process for
>> accepting patches into the main branch? Is there no scrutiny/review that is
>> done at that point?
>>
>> Regarding buffer overflows, I can definitely look at running address
>> sanitizer on the latest commit, this should help catch such issues.
>>
>> Regarding "we're going to stuck around and be here to fix what needs
>> fixing" - again, I'm a bit lost. The code is already in the main branch -
>> it's already "out there". By no means to I intend to drop a release and
>> disappear of the face of the planet, but I'm also not prepared to commit to
>> resolving any and all issues that come up at any time after the release.
>> That seems like a bit of a big ask.
>>
>> What is a "cgull" commit?
>>
>
> cgull is a contributor to mosh, who did the last few releases.
>

😅 I probably could have figured that out if I had checked the commit
history.

Thanks!

>
>

>>
>>> - Ensure oss-fuzz is _actually_ running against mosh
>>>>     - add fuzz targets as needed to cover commits since latest release
>>>>
>>>> Thanks again!
>>>>
>>>> Wolfgang E. Sanyer
>>>>
>>>
>>> Looks good to me. I'd love if you kept mosh-devel cc:ed on the
>>> conversation between you and Alex/Ben/Quentin, but I will leave it to you
>>> to work out a process with them for how you'd all like to get this done.
>>> (And if you want me involved for an occasional call, let me know.) Welcome
>>> again!
>>>
>>
>> As I stated above, I'll try to keep all the conversations here or on the
>> github, so that there is a record of them.
>>
>>
>>> Sincerely,
>>> Keith
>>>
>>>
>>>> El jue, 27 ene 2022 a la(s) 03:09, Keith Winstein (keithw at mit.edu)
>>>> escribió:
>>>>
>>>>> Hello Wolfgang,
>>>>>
>>>>> Welcome, and thanks for writing! We're happy to have you involved. Let
>>>>> me loop in Alex (our RPM package maintainer) who is willing to help get
>>>>> this off the ground, as well as Quentin Smith (one of the Mosh authors) and
>>>>> Ben Barenblat, who are also interested in helping make this happen. I know
>>>>> Anders and Andrew (the other currently active stewards) would also support
>>>>> this, and may want to contribute time to a release as well.
>>>>>
>>>>> I think one good goal would be to document the release process, which
>>>>> should be gleaned pretty easily from what we've done in the past: put out
>>>>> an "rc" (release candidate) release (with some care with the "~" to make
>>>>> sure we don't accidentally clobber our Debian/Ubuntu versioning order) and
>>>>> call for the community to test it rigorously.
>>>>>
>>>>> Since we've lost our previous maintainer, and because he had made some
>>>>> commits after the last release, we're also starting from a bit of a deficit
>>>>> here. Before we cut a release, I'd be most comfortable if we:
>>>>>
>>>>> (1) look over the commits that have been made since the previous
>>>>> release pretty carefully. I would be unhappy if perhaps one of the commits
>>>>> that introduced truecolor support introduced (e.g.) a buffer overflow
>>>>> vulnerability in the terminal emulator. Not saying I think this has
>>>>> happened, but given the transition in personnel, these commits deserve some
>>>>> scrutiny.
>>>>>
>>>>> (2) wrote some fuzz targets, both pre- and post-decryption, and
>>>>> submitted them to the oss-fuzz repo (
>>>>> https://github.com/google/oss-fuzz/tree/master/projects/mosh), and
>>>>> made sure that some fuzzing actually happened. We've been on oss-fuzz
>>>>> itself for over five years but nobody has written fuzz targets for Mosh, so
>>>>> I don't think any actual fuzzing has happened.
>>>>>
>>>>> Are you interested in helping write fuzz targets, or with any other
>>>>> part of this process? I am happy (honestly, I'd prefer) to stay pretty
>>>>> hands-off here -- I'm sorry we lost our previous maintainer and hadn't
>>>>> planned on returning to active duty. Alex, Ben, and Quentin have been
>>>>> around the block here and have also been involved in Mosh basically since
>>>>> the beginning, and are happy to mentor you in this. Please let me (and
>>>>> them) know your interest.
>>>>>
>>>>> Sincerely,
>>>>> Keith
>>>>>
>>>>> On Wed, Jan 26, 2022 at 7:05 AM Wolfgang E. Sanyer <
>>>>> wolfgangesanyer at gmail.com> wrote:
>>>>>
>>>>>> Hello mosh development community!
>>>>>>
>>>>>> My name is Wolfgang E. Sanyer. I am a long-time
>>>>>> programmer/open-source contributor, and a recent (very recent, just started
>>>>>> Jan 10th) professional software engineer. If you'd like to take a look at
>>>>>> some of my work, my github is https://github.com/ezzieyguywuf
>>>>>>
>>>>>> I am very interested in contributing to the development of mosh:
>>>>>> specifically, I would like to help do the work necessary to cut a new
>>>>>> release. From what I can see, the last release was v1.3.2 in July 2017.
>>>>>> Since then, there have been a number of commits, most interesting to me
>>>>>> being 6cfa4ae which adds true color support.
>>>>>>
>>>>>> While I do not have a lot of experience with the "Release
>>>>>> Engineering" work necessary to do this successfully, I am very motivated to
>>>>>> get this done as it will greatly improve my daily workflow. Also, I feel
>>>>>> confident that given the appropriate learning resources, I can get
>>>>>> up-to-speed on what is needed to successfully release a new version of mosh.
>>>>>>
>>>>>> Please let me know your thoughts on:
>>>>>>
>>>>>> 1) the general thoughts around cutting a new release (there seems to
>>>>>> be some discussion against doing so)
>>>>>> 2) any next steps needed to move forward with cutting a new release
>>>>>>
>>>>>> Thank You!
>>>>>>
>>>>>> Wolfgang E. Sanyer
>>>>>> _______________________________________________
>>>>>> mosh-devel mailing list
>>>>>> mosh-devel at mit.edu
>>>>>> https://mailman.mit.edu/mailman/listinfo/mosh-devel
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mit.edu/pipermail/mosh-devel/attachments/20220128/fe8f5e8c/attachment-0001.htm>