On Mon, 13 Jul 2020 at 13:53, Rob Tompkins <chtom...@gmail.com> wrote: > > > > > On Jul 13, 2020, at 8:51 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > On Mon, Jul 13, 2020 at 8:48 AM Rob Tompkins <chtom...@gmail.com > > <mailto:chtom...@gmail.com>> wrote: > > > >> > >> > >>> On Jul 13, 2020, at 8:46 AM, Gary Gregory <garydgreg...@gmail.com> > >> wrote: > >>> > >>> Is there still room for corruption after a vote passes when the files are > >>> moved in SVN from the dev to dist folder? > >> > >> Good question….but I would think we would notice that after the fact with > >> an alert like the ones that we’ve gotten about signatures not matching. So > >> I would think that we wouldn’t worry about it? > >> > > > > I hope not! ;-) > > I think this is another case where we need @markt to weigh in.
I don't think it's possible for an SVN rename to corrupt files, but of course the names might be mangled or some files may be overlooked. Another reason for checking hashes is that sometimes artifacts have to be fixed and uploaded anew. The hash can be overlooked (I think that has happened in the past). We need to be checking what the consumers will see. > -Rob > > > > > Gary > > > > > >> > >> -Rob > >> > >>> > >>> Gary > >>> > >>> On Mon, Jul 13, 2020 at 8:29 AM Rob Tompkins <chtom...@gmail.com> wrote: > >>> > >>>> I’ll take the shell scripts that I’ve been using and enrich them a > >> little, > >>>> and then I’ll share them with folks.I think we can likely put them in > >> one > >>>> of the plugins so that folks can simply run the script to move and > >> download > >>>> all the artifacts in their checkout of the svn directory. > >>>> > >>>> Cheers, > >>>> -Rob > >>>> > >>>>> On Jul 13, 2020, at 8:12 AM, Rob Tompkins <chtom...@gmail.com> wrote: > >>>>> > >>>>> Yes…I agree with that need. I was wondering if the release plugin was > >>>> doing that or nexus itself was doing that. But, I definitely understand > >>>> that they show up in nexus when using the plugin. > >>>>> > >>>>> Cheers, > >>>>> -Rob > >>>>> > >>>>>> On Jul 13, 2020, at 8:10 AM, Gary Gregory <garydgreg...@gmail.com> > >>>> wrote: > >>>>>> > >>>>>> Rob, if you plan on working on the release plugin, can you see if > >> there > >>>> is > >>>>>> a way to have the VOTE not generate checksum lines for ASC files? IIRC > >>>> we > >>>>>> do not need checksums for ASC files. > >>>>>> > >>>>>> Speaking for corrupted uploads, does the Maven deploy goal check that > >>>> its > >>>>>> uploads are sane? > >>>>>> > >>>>>> Gary > >>>>>> > >>>>>> Gary > >>>>>> > >>>>>> On Mon, Jul 13, 2020, 08:04 Rob Tompkins <chtom...@gmail.com> wrote: > >>>>>> > >>>>>>> This all makes sense to me. Many thanks for the feedback here. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> -Rob > >>>>>>> > >>>>>>>> On Jul 13, 2020, at 5:12 AM, Mark Thomas <ma...@apache.org> wrote: > >>>>>>>> > >>>>>>>> On 13/07/2020 06:43, Stefan Bodewig wrote: > >>>>>>>>> On 2020-07-12, Rob Tompkins wrote: > >>>>>>>>> > >>>>>>>>>> given the consistency of the signatures from the plugins…do we > >> need > >>>> to > >>>>>>>>>> check them for releases anymore? > >>>>>>>>> > >>>>>>>>> Yes, please. Not everybody uses the plugins and even if everybody > >>>> did a > >>>>>>>>> misconfiguration could be pulling in the wrong key or a key not > >>>>>>>>> available from the expected download location. > >>>>>>>> > >>>>>>>> +1, for several reasons > >>>>>>>> > >>>>>>>> It also catches corrupted uploads. > >>>>>>>> > >>>>>>>> It is simpler to fix during a release vote than after a release > >> where > >>>>>>>> we'd have to at least consider the possibility of malicious activity > >>>> and > >>>>>>>> respond accordingly until we could prove it wasn't. > >>>>>>>> > >>>>>>>> Mark > >>>>>>>> > >>>>>>>> > >> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> <mailto:dev-unsubscr...@commons.apache.org> > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> <mailto:dev-h...@commons.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
