I agree, but the vast majority of the packages are submitted by forum users like you. Perhaps I should do a background check for each package, but this would require a tremendous amount of time, so I only remove binaries to prevent a possible infection.
Please note that some well known package can contain binaries(dll, so), but it was explicitly requested by the package developer, without them the package wouldn't work properly.
A good thing that you at least uphold some standards that you are able to manage. However, it raises another concern, namely the integrity of the code itself.
I fully understand that you do not have the time to check each and every offered package yourself.
How about not accepting any packages that do not have an origin for their sources ? That is a thing that could be automated ? Each package contain sources, and they should match with those from their origin. In case it doesn't then such package will not be accepted or indicated as a package without (official/matching) origin.
That will put some of the burden back to the submitter. I fully realise that will probably also mean less packages being submitted. However, since i've given some of these things some though, I don't think you are able to relieve yourself without making some of such (perhaps harsh) decisions.
afaik people who genuinely maintain a project that support OPM would have no issue whatsoever with such a rule as they already have this kind of infrastructure set up.
At least that way the end-user would be able to either not being offered untrusted sources or at least ones that are indicated as such (in which case the end-user can decide him/herself if it's worth the trouble, e.g. you would probably not have heard from me in the first place instead of being a pita now
)
By the way I removed Internettools from OPM, the package is actively developed and the author regularly visits this forum, as you correctly mentioned in one of your previous posts.
Thank you for doing so. Although that would perhaps be a bummer for the person who created and submitted the package, it is imho better this way.
That would be great! This project is no longer something I enjoy.
I feel your burden there. In that regards I really wish I could be of more help. Note that i'm often thinking about how things could be improved but, it seems there are so many obstacles in the way that things become stuck when working out solutions that have a too naive approach.
One of the things I still miss a little is your input. Perhaps you already expressed yourself in the past (that I am unaware off) but it would be nice to know what you yourself think could be done to relieve your stress. And by that I meant without just simply turning things over to someone else. You must have some idea's about that, or not ?
I can suggest a multitude of changes that could perhaps improve things but for some of them I have no idea if they are actually feasible to realise (without too much work).
For example, I've seen a mention of some sorts of quality system so that users could submit their experience or offer a grade for the package. Bad experience, bad grade. Good experience, good grade. Too much bad grades call for (manual) inspection and/or removal. At the same time you mentioned that being a shiteload of work for you to be able to incorporate such a thing into OPM (not to mention adding/maintaining an infrastructure for keeping track of that information).
In theory it is a good idea, as it would also be able to gather some information with regards to popularity of a package (although perhaps you are able to see some of that already because of the number of downloads/installations of a particular package). The more a particular package is valued the more attention it deserves, in case people report issues. But in the end we don't know if self-regulating in such a way is going to work for OPM.