[mosh-devel] Introduction: Wolfgang E. Sanyer
Keith Winstein
keithw at mit.edu
Thu Jan 27 13:37:30 EST 2022
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.
> 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.
> - 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!
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/20220127/3db23b2c/attachment.htm>
More information about the mosh-devel
mailing list