[mosh-devel] Introduction: Wolfgang E. Sanyer

Fri Jan 28 16:13:17 EST 2022

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.

>
>
>> - 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/304a91bf/attachment.htm>