3 ms·
If the signature reqt is attached to the package metadata, the new package just removed it. If it's part of their custom build system, what signs third party pa
by angry_octet 6y ago
If the signature reqt is attached to the package metadata, the new package just removed it. If it's part of their custom build system, what signs third party packages? Would it just sign the new one anyway, because how does it know which ones should have PayPal internal signing? Or are you proposing manual controls? shudder
Channels and priorities embedded in the package tools are a better approach, combined with something like Artifactory. Some channels might require packages are signed, and possibly monotonically versioned.
- magicalhippo 6y ago> Or are you proposing manual controls? That's what we do. Dependencies are committed to our repository, so changes show up as diffs which are looked through then. Then again we don't use libraries for padding strings and such...
- angry_octet 6y agoI've found that it is easy for discipline to slide on manual controls. It starts off rigourous and tails off into being done infrequently (which makes it a big job) and perfunctorily. This will save you from things that hit the bleeding edge, the idiots who pull from latest on a prod instance, but leaves you exposed to the patched bugs, with increasingly good exploits. Diff inspection will catch some obviously bad things, but it will rarely catch anything clever. So it would be down to luck, if you had merged in this patch before it was spotted/announced. Unless you have something to separate the namespaces? Check for conflicts? I guess CI might work, hoping your CI machines are sandboxed.