On Fri, Jan 28, 2022 at 3:37 PM Wolfgang E. Sanyer < wolfgangesan...@gmail.com> wrote:
> > > El jue, 27 ene 2022 a la(s) 13:38, Keith Winstein (kei...@mit.edu) > escribió: > >> On Thu, Jan 27, 2022 at 3:49 AM Wolfgang E. Sanyer < >> wolfgangesan...@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 (kei...@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 < >>>> wolfgangesan...@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@mit.edu >>>>> https://mailman.mit.edu/mailman/listinfo/mosh-devel >>>>> >>>>
_______________________________________________ mosh-devel mailing list mosh-devel@mit.edu https://mailman.mit.edu/mailman/listinfo/mosh-devel