Some organizations have concerns about using precompiled binaries provided by third parties.
To "vet" a third-party provided binary would be a process to simply compare the provided binary against the one that you could create yourself using the same source code. A sufficiently motivated third-party could take a perfectly clean/safe binary, inject their own modifications, and distribute that modified version as if it were the original version. I haven't seen this happen myself with any Java libraries, but it could occur, at least in theory (and assuming you don't pay attention to checksums - also realize the same person who could secretly modify the binary could also modify the checksum). As with everything, you need to think about what risks you are concerned about, then devise processes to mitigate those risks. No one here can dictate the correct approach for your organization. Wayne On Fri, Oct 16, 2015 at 9:33 AM, <[email protected]> wrote: > The Maven Introduction to Repositories documentation contains a section that > describes setting up an internal repository. > > In that section is described an option to manually download and vet releases, > apparently of a remote repo. > > What is meant by "vet"? Can you provide an example of how a repo release > would be vetted? I suspect this is highly dependent on the intended use of > the repo, but I'm just trying to get a general idea of what is involved. > > Thank you. > > Mike > > Michael Tarullo > Contractor (Engility Corp) > Enterprise Architect > NSRR System Administrator > FAA WJH Technical Center > (609)485-5294 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
