[mosh-devel] Introduction: Wolfgang E. Sanyer

Fri Jan 28 15:36:56 EST 2022

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?

> - 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/2d159d01/attachment.htm>