I don't think it is quite that simple.
Your not just trusting that person will do the right thing. You are also trusting that they also have good operational security. It is precisely this sort of trust model which resulted n a number of GNU/Linux distributions being compromised in the past. The same thing has occurred with NPM and other 'public' repositories. It wasn't that people who had access did the wrong thing, but rather people who had access who failed to secure their systems adequately.
You only need to do a search of places like github to see how often people accidentally commit sensitive data or look at the analysis of repositories that have been compromised to see how often this occured because passwords were poor, keys were not secured or sensitive data was accidentally posted to public forums.
The only real solution is one where each package maintainer is isolated from write access to code/packages they are not authorised to maintain. The challenge is, such setups usually also result in higher levels of maintenance overheads and that can often be a challenge for an organisation which needs to walk a tight line wrt funding.
To make matters worse, typically, it is almost impossible to have good security retro fitted to a solution this is something which needs to be designed into the architecture from the start. This means that to fix this problem would require a considerable amount of work and change. The change part is extremely difficult as most people simply don't like change (as is evident in many of the discussions about updating how we handle patches, pull requests, defaults, etc).