El vie, 28 ene 2022 a la(s) 16:13, Alex Chernyakhovsky (acher...@mit.edu) escribió:
> > > 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. > 😅 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 (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
