That plugin approval

Discussion in 'BukkitDev Information and Feedback' started by blint66, Jul 16, 2014.

Thread Status:
Not open for further replies.
  1. Offline


    What do you guys tend to prove with such huge argumentations here? What I see is that there actually really is big deal here, you're using hate to protect any possible change, it is really scary for a community that pretend to be open.

    I may have a lack of tact, but your susceptibility really don't help. If you feel offended, what do you think about me? I come with detailed ideas, justified arguments and counter-counter-aguments, and here you come with smoke screens made of wolrdwide example and kitty quotes. Anyway why would you care, just stay in your fine little world ;)
  2. Offline


    I have responded to every one of your ideas with reasoning stemming from years of experience, sound judgement and factual statements. The fact that you can so easily dismiss what I say by stating I am using hate to counter change is unfounded and, being very blunt here, quite absurd. I have wasted quite a bit of my time responding to your post it seems, as nothing I have said has actually been considered. So in that, you are correct. I could have better spent my time doing something productive rather than attempting to shed some light on a misguided idea.

    I have a strong feeling you've walked away from this discussion still 100% certain you know best, even with multiple people telling you otherwise. You keep repeating that we are a community that pretends to be open, yet you haven't ever considered the possibility that you are wrong. If you cannot consider that possibility, there was never a point having a discussion with you, as all you've heard is that we've rejected your idea without ever hearing why your idea was rejected. You dismiss that rejection, not based on the facts and reasoning presented, but because you believe we are closed minded.

    This was never a discussion, this is simply you stating over and over again that you feel you are right, and ignore everyone else who states otherwise. Go on believing what you want to believe, but I strongly recommend you consider that you are wrong. I have considered your points. I have considered that I am wrong. Nothing you have said leads me to believe this is the case, as your argument is backed by no reference material, or experience in this situation.
  3. Offline


  4. Offline


    This thread is hilarious. It probably helps that I read all of blint's posts in a Garfield voice.
    Lolmewn likes this.
  5. Offline


    ZachBora, don't worry there is no relation between installers and Bukkit.

    Anyway I'm sorry for you, and I agree bloated installers for Windows software really are a scourge.
  6. Offline


    A failure to comprehend Rice's theorem puts you in absolutely no position to argue whether or not something is automatable. It's as simple as that.

    Comparing Bukkit plugins to StackExchange is a desperate attempt at a classic, pseudo-scientific approach to debate. Your arguments are hysterical, childish, and detrimental to the original purpose of this thread. Do you honestly think insulting the only people capable of making your ideas a reality is going to help you make your case? Do you understand the purpose of debate at all? No one wants to fight you, so drop the pathetic sophism, put down your fists, and instead, respond with your brain and a little bit of respect for the rest of the community. Maybe then you will be taken seriously, but for now, you're only making yourself look like a fool, whether you like it or not.

    If you think that the StackExchange system is perfect, you clearly haven't asked a highly debatable question yourself. The system works for stuff like StackOverflow because of the context - it is not by definition generalizable. For one, it is based entirely on the idea of convergence, a concept that, in this particular application, very heavily relies on time - the very variable you are trying to eliminate. Implementing Bukkit plugin file approval as a StackExchange system means everything will slow down. New plugin developers have no way of gaining the initial trust required for server owners to download their plugins. Someone has to be the guinea pig, and no one wants to be. They will be waiting until they think it's safe to download, while some will be reckless and just download anything. A proactive approach to removing malicious plugins provides a fixed barrier between the server owners and the developers of malicious plugins. Your approach removes that barrier, releasing the problems into the open where they will either damage the guinea pig server owners or create prejudice against unknown developers in the community. Plugin approval works because the people approving the plugins are (mostly) seasoned software developers, who all know what they're doing. Your clearly haven't considered the amount of oblivious server owners and incompetent plugin developers.

    Your ideas are not thought through. If they were, this thread would not be full of people explaining to you why they aren't. Recall that the purpose of debate is to enlighten, not to force your beliefs down other people's throats. No one is going to take you seriously if you don't show them the same amount of respect. A man convinced against his will is of the same opinion still.
  7. Offline


    The original post of this thread has been updated with these "arguments" that are not, because I'm only giving some additional suggestions (which are argumented). Look who's using statements that are hysterical, childish, [or] detrimental to the original purpose of this thread (a certainly not insulting qualification by the way).

    I never pretended this, again I must repeat: next time please read the whole bunch of heavy posts before adding a new one here. If I meant StackExchange was the solution, I'd have suggested "yay, let's move to StackExchange!". Wasn't I just giving examples where the community was a great part of the lead?

    From my general experience and what I see naively in Bukkit world, I'm just spotting some points that seem possible improve, asking for people to see the possibilites further than where the barriers have been pleaced. I never pretended to be the wisest of all... and that may be both the reason and the interest in this topic.

    After reading many people that feel like me here, clearly seeing also that many other are afraid of being sanctioned under moderation's pressure, I finally already took an intermediate conclusion on a deeper problem: how to handle Bukkit community. No, I'm not ignoring all your answers and I really do my best to get the cause and the consequences of the actual process. I did got angry, I'm sorry for that, but I'm sure you understand that it makes one crazy when someone denies a wide suggestion with unappropriate agruments and pretending he measured the whole scope of what one could mean.

    Maybe I wasn't clear enough, not speaking English natively may play against me, and if yes I'm sorry for that too. Anyway I know I made my point over the preceding posts, without mentioning theorems or principles (edit: or kitties and songs?) to look more scientific. I'm not here to prove anything. Just helping fixing a problem that obviously exist considering the number of posts related to this topic and the massive cost of approvals to be handled by BukkitDev.
  8. Offline


    blint66 yes, you made a suggestion, and it was deemed not good, because it doesn't solve the problem. You still need manual inspection of each file to prove it not malicious, since an automated check cannot catch many of the possible malicious possibilies. Your suggestion also seems to require plugin developers to open source their plugins, something which is not required by current bukkit approval system.

    These points and more were made against your suggestion, but you just claimed you know better, without actually showing, and proving, how your suggestion would fare better against the current approval system, while in the current enviourment. Since you never prove so, it appears more and more like the thread Wolvereness linked - all buzz and no useful information in sight.
  9. Offline


    Oh, really? Did I make one suggestion? Please quote how all of my suggestion have been deemed not good.

    Oh, really? Since when is a human check a proof? Even Lolmewn seems to agree:
    In any case, we're talking about compromises, and open-sourcing can in may ways help, at least by considerably reducing time required by approvals, what I already argumented.

    I've just showed that what you say is unjustified, I think this kind of post could totally be reported because freely aggressive, really disappointing from a moderator.

    I don't know why I'd make suggestions for myself, it's just for Bukkit's sake.
  10. Offline


    blint66 "freely aggressive" - but insulting other people because they disagree with you is fine!
    I have no idea why are you still trying to beat this horse.

    And you STILL can't show actual solid data, proof its better, or examples of how you plan your suggestion would work.

    Yes, manual on top of automatic validation may not be perfect, but only automatic validation is much worse.
  11. Offline


    Necrodoom I'm sorry you felt offended but you obviously attacked me with no specific reason, so what I said was justified thus not insulting.

    Eventually, back to the main topic: it was pretty hard but I'm glad the discussion could make steps forward. Some of my original ideas eventually don't apply to Bukkit's model for many good reasons. However as far as I could sum all this up, open sourcing still could help gaining time.

    Let's forget instant uploads in exchange of fully automatic validation, I can't stand war anymore.

    Now let's talk about open-sourceable project mode, based on trusted repositories:
    • Open-source mode should be a developer's choice. Today's mode must remain for developers that don't want to share.
    • File releases wouldn't be uploads anymore, but a branch/revision number
    • Bukkit platform builds itself the file to download from source
    • BukkitDev team will be able to check original source
    • As repository would be trusted (either Bukkit repo or Github project), a diff between two releases would be possible and hugely reduce the work needed by BukkitDev, even if full checks can periodically be required to perform just in case.
    Considering these non exhaustive list of advantages, I am sure we can help BukkitDev with it.
  12. Offline


    blint66 ah, so basically what Skye two pages back.

    You mean you never tried to insult or talk down upon anyone before..? OK then.
  13. Offline


    Necrodoom No, I'm not talking about continuous integration but only about trusted repositories basis. That makes a slight difference. The ideas are close tought, Skye's great idea may have made its way into my brain. Let's just consider I took his idea and improved it.

    At least, we both contribute to help moving forward, that's why I said I appreciated Skye's contribution.
  14. blint66 Bare in mind, that the following post is based on the ideas presented in your last post (open source system) as opposed to other ideas (automated checking), since you said that you did not wish to discuss them further.
    • So the current system would apply to all of those who do not want to use an open-source approach, and the new system will apply to those who do?
    • I'm confused on the overall benefit of this?
    • I assume this means plugin developers will now also have to learn some form of dependency management (like Maven)? This isn't really a benefit in my mind.
    • They have to check the source either way, there's not a great deal of difference in original vs decompiled except in readability. Not really a huge advantage, I don't think.
    • If you're going to periodically run full checks, you might as well just do a full check each release - it's a simpler idea, and periodically checking could just as easily waste time as it could save it.
    The real point that you are probably missing has already been mentioned before. This system that you're proposing isn't something that you can just easily flick a switch to enable - with the current system, it isn't possible. It will require a lot of work in order to make the system a reality, and some of that work may need to come from parties not under Bukkit's control (i.e. Curse).
    We're not saying your ideas hold no possible benefit, because sure, there are some benefits to some of your ideas. But what we're saying is, do the benefits that your ideas would provide outweigh the time and effort that would be required to implement them? Probably not. And that is why your ideas are not being implemented - not because they provide no benefit, but because they're not worth it.
    jthort likes this.
  15. Offline


    Hi AdamQpzm,

    Yes, this would be in the package. Making a basic Maven project isn't a big deal, a short wiki page would be enough to explain where to start with. Moreover, this would incitate developers to the use of best practices, and eventually drastically simplify dependency management, so I even think this is an additional benefit.

    I disagree: readability is always a good factor for time gain. While checking code, you're most supposedly to come back from parts to others (that you may have already read) because of method calls. Readable code make you gain much time by understanding algorithms way faster (especially if the code is commented, let's dream a little!).

    What do you mean? Let's take a period of five releases:
    • First plugin check: full check
    • Releases 2, 3, 4 and 5: differential (fast) check
    • Release 6: full check
    Based on a medium size project, let's assume big changes each time: 50% of total files impacted.
    Time gained: approx. 40% for a bad scenario.

    Never supposed it was straightforward to implement.

    May I have some details, like a proof or some realistic stats? Or is it just your own judgement?
  16. Offline


    I think the speed of plugin review is a bit of a problem, and that there are better solutions than assigning more people to the task. It's no major problem, but it's an opportunity for a new community (or an established one) to do it better.

    The biggest issue (or non-issue, depending on what you consider cost-effective) of reviewing only the commits associated with a newer build is that malicious code which slips through will not be checked again. Perhaps this problem can be mitigated by requiring code review from multiple staff members?

    The drawback to consider would be slower approval time for initial uploads and major revisions with code changes that make up more than (1 / # required approvals) of the plugin's code. However, if the number of plugin revisions is far greater than the number of new plugins, it may be faster even for initial uploads due to the extra time from not having to evaluate entire plugins every revision.
  17. Offline


    You're right Skye, even if we'd increase full check interval against more "full-reviewers", if a malicious code would slip-in that would be a "jackpot" for the malicious developer. But would he actually want to make changes of his approved malice? I'm not convinced it would really change so much from today's process anyway on this point, don't you think?

    On top of that, let's not forget that his source is open, and that anyone on the web can check his code:
    • Chances that open-source plugins are malicious is very close to null, because a one is not likely to think open source when he wants to make some trick
    • The rest of the community will be an actual support that will be able to spot malices!
    Moreover, if two (or more) developers would both approve a full-release, that would be a considerable security improvement compared to today's situation.
  18. Offline


    Its never a good idea to trust the developer when checking for malicious code or intent. Comments, while may seem like a good idea, are only good to read if you can 100% say the developer isn't trying to pull a fast one. Can you actually trust his comments to be genuine and not attempting to mislead you into thinking the code is safe when its actually cleverly hidden malicious code? Of course not. Basic security principle requires you to not trust anyone, ever, even if they are a really swell guy.

    So when we do the first check and miss some malicious code, because we're human and mistakes can be made, we can't possibly catch that mistake until the 6th version uploaded? Doesn't sound very ideal at all. Checking the entire source, every time, ensures that if Person A misses something, Person B may catch it, or at very least, increases the probability of that malicious code being caught the very next release. Probability is low that Person B would miss it as well, but if that happens, Person C could catch it. Your system would ensure that the malicious code isn't caught until Person F checks the code, and you better hope he catches it, or else it won't be caught for another 4 uploaded versions, at which you really hope the next person doing the full review catches it. Now also keep in mind, your system promotes lazy checks. Person doing the 6th review is less likely to care about making damn sure the plugin is free of malicious code, because 5 people have already signed off on it before their check. Promoting a full review, every single time, reduces this lazy attitude, and ensures a higher probability of catching malicious code on subsequent uploads.

    Just to diffuse your anticipated response saying something along the lines of "Open source code means the community can check the plugins too!" (I was too late with my reply, you stated this in the very comment above mine), I'll point out that this is already possible with the current system, so nothing is gained from the non staff community by going with this method. We end up with a net negative approach in terms of safety using your system, with a slight net positive gain in approval speed. Again, we're back to faster speed at the expense of safety. This goes against the core principles of BukkitDev.

    We had this conversation 3 years ago among the staff. Simple tip for you, if you want to suggest an idea and think "This is so easy, why isn't it done?" its likely because its not as easy as you think, or as good as you think, and therefor already ruled out. You're still thinking "How can I make this faster?" without considering (or worse, dismissing without care) what you're giving up to gain that speed.
  19. Offline


    Wasn't I just giving arguments as to why your ideas aren't thought through? Your example of the community being a great part of the lead is useless, because there is no fair comparison between the two communities. My point is simple: apples and oranges.

    This right here. This is your problem. You're "spotting points that seem possible to improve", but when presented with arguments as to why that's not the case, you throw a tantrum. By not accepting the responses you are given by people who know more than you about the system you are trying to change, you make yourself look like a snooty armchair programmer, which makes it extremely difficult to take you seriously. When in doubt, ask, don't assume.

    Please cut the "oppressive rulers"-bullshit (it's on par with appealing to "free speech" when moderators remove offensive posts). It's getting old, and it's making you look even more hysterical, like a village idiot running around without his pants. And yeah, I'm perfectly justified in saying that, because no one here is forcing you to do anything. You can pack your bags and leave, and you are more than welcome to submit your plugins to other sites and services. People don't "feel like you". Other similarly ignorant people also complain about the approval time because they hit the Submit button and want the files to be available immediately. The only two things you have in common with the rest of the impatient kids is that you are impatient, and you know nothing, Jon Snow...

    Considering you clearly haven't thought this through either, I am sure I can help you understand the full context of what you're suggesting.
    • A "trusted repository" changes nothing in terms of approval times - the BukkitDev staff will still have to wade through all of the code. Besides, what makes you think that it isn't possible to run a diff on two different versions of submitted jar-files? Decompilers are deterministic, you know...
    • There is absolutely no guarantee that the original source code will be more readable than the decompiled class files. If you think so, you clearly haven't seen the myriad plugins written by people who know so little about the Java conventions that you'd think they just started their computer and facerolled the keyboard until suddenly a bunch of Java source files popped up on their desktop. Indeed, decompiled source code is consistent and predictable, and all of the syntactic sugar is removed, leaving you with very basic constructs all over the place. Here's a war story to put things in perspective for you:
      Show Spoiler
      At my university, we have an "Ants & Spiders" programming contest in the last weeks of the introductory programming course. The point of the contest is to write the "minds" of the ants so they eat all the sugar without getting eaten by the spider. One student submitted a solution that worked incredibly well and got the highest scores ever, and the professors and instructors couldn't figure out why, until all of a sudden an instructor said "the scroll bar at the bottom is very, very tiny". They scrolled all the way to the right, and found, 10,000 characters out, a single line full of code that wasn't allowed in the project (teleporting ants, using static fields to give all the ants a "common mind", etc.).
    • The most prominent version control system is git, and git supports rewriting of history (albeit highly advised against everywhere). Thus, to implement your idea, this functionality has to be disabled for obvious reasons. Your suggestion really boils down to a tight coupling between a project and where it is distributed. How is that a good thing?
    • There is a huge difference between a file server and a build server. Are you gonna pay for the upgrades necessary to not slow down DBO even more than it is already?
    So, considering this non-exhaustive list of disadvantages, complications, and "buts", do you think you could spend a little more time approaching things from other perspectives than "Bukkit is evil and I hate waiting for my shit to be approved"?
    Please just stop.
  20. Offline


    I haven't read all the posts here but thought i'd throw in my 2 cents after reading some of the other suggestions and what not. I like the idea of like trusted or if you link to github kinda scenario but can see TnT's side as well where people could slip in malicious code still. What about making it so that if someone uploads something not a jar file it gets put into a queue so that a DBO staff member has to manually check it, but if they upload a jar file some sort of automated decompiler scans through the source real fast looking for specific imported classes that could be used for malicious intent. DBO staff can add any classes they think could be used in such a manner and if a jar file has those specific imports it gets placed into a queue for manual verification, those that don't get the green light other than maybe major version changes.
  21. Offline


    You probably should, since what you're talking about has already been discussed and refuted, but a recap for you because I love your avatar:

    1. Rice's theorem.
    2. Fully qualified type names.
    AdamQpzm and jthort like this.
  22. Offline


    I agree with this. Anything major that slips by staff will likely be reported by a user long before the developer does something to risk being caught, unless it's a security hole due to programming error.

    However, I think how Bukkit/Curse allows us to license our plugins as we see fit is a good thing, and that mandatory open sourcing of a project would work against the community. Building projects from source uploaded to a private repository would be a different thing though, as developers already know that Bukkit staff will decompile and scrutinize their code.

    If people are too lazy to fully review a snippet of code because someone else already did, there are definitely going to be people who are too lazy to review the entire source because most of it was reviewed countless times. I think this lazy attitude is a risk in any review process with redundancy.
  23. I think the less we force people to learn in order to publish plugins, the better. :) I personally don't particularly like using Maven, especially for smaller projects, and know some people of the same opinion.
    I can't argue that more readable code would speed things up. However, I would say that a large part of the readability comes from the way it's been programmed rather than the fact it's been decompiled (and the obfuscation of course, but BukkitDev plugins shouldn't be obfuscated anyway). And comments can be helpful, but each line will still need to be checked regardless of whether or not there are comments :)

    Ah, my apologies, my periodically I assumed you meant periodically as in by time, as opposed to every X release. Either way, this system does compromise security somewhat, since it will take several releases until it's checked again. If you consider a plugin that doesn't update very often, then it may be a long time and several releases until it's caught. Here's a counter scenario. Let's assume that a plugin updates once every two months, and that malicious code was inserted in the first version. Unfortunately, the malicious code is missed both the first and the second times that a full check is run, but is caught on the 3rd (no offense BukkitDev staff, you do a fine job really :)) and let's assume it was malicious but unnoticeable to server owners, and went unreported.
    With the current system:
    • Version 1, month 1 - Full check run, however malicious code slips through
    • Version 2, month 3 - Full check run, however malicious code slips through
    • Version 3, month 5 - Full check run, malicious code found, plugin removed!
    • Time to spread: 5 months
    With your system:
    • Version 1, month 1 - Full check run, however malicious code slips through
    • Versions 2, 3, 4, and 5, months 3, 5, 7, and 9 - Diff checked, therefore code stays
    • Version 6, month 11 - Full check run, however malicious code slips through
    • Versions 7, 8, 9, and 10, months 13, 15, 17, and 19 - Diff checked, therefore code stays
    • Version 11, month 21 - Full check run, malicious code found, plugin removed!
    • Time to spread: 21 months
    Ah, but there lies a rather big problem, one that shouldn't be overlooked.
    I don't actually have details about how long this sort of thing would take to implement, I'm by no means an expert. I mainly based it on both my own judgement and some of the things that those who know far more than me about this sort of thing have said.


    By the way, I have an extension that replaces the word keyboard with leopard, so this sentence looked particularly more violent on my screen :)
    SGrayMe likes this.
  24. Offline


    I'm not documented enough about this, here would be (at last...) a valid limitation! Hopefully you've found a solution to this issue yourself: we still could do manual diffs!

    I definetely agree, I mentioned this in my suggestion.

    This case has an unrealistic probability to happen, let me explain. Let's only consider the basic critical case that we already don't want: malice detected on second full-review. Yes it could happen with regular reviews and Skye already noticed it and suggested double check on full reviews (even greater security than from now).

    Let's suppose both didn't notice the malice..! (what we really already could afford) Next check would be diffs. But these checks remain human, and there anyway is a chance that these guys spot some malice where they wasn't supposed to check. You know, if we're talking about efficient code reviewing (which is BukkitDev's case I'm sure), this implies "intelligent" checking, so if the reviewer has some doubt on how is called a method is some diff, he may wants to check calling source, other files, and possibly spot weird activity.

    Anyway, consider:
    full-source double check + open-sourcing worldwide pressure + community checks

    If someone bypasses all this without being reported by server owners, it would be likely the malice is harmless.
  25. blint66 IF the diffs have nothing relating to the malice, it's no more likely that some just checking diffs would spot the malice than any other line - it's not supposed to be a full review after all. This is especially the case if the malice is in a different class file altogether, since there will definitely be no real reason to go snooping around in there, unless you suspected there was something there.

    Sure, double checking increases the chances of it being found, but they're currently checked every release - you'd either have less checks overall which would result in less security but faster approval, or more checks with better security but slower approval. With this case you can't get better speed and better security. + We've already said how pressurising developers into open source isn't necessarily a good thing. My BukkitDev plugins are open source, but if you forced/pressured me into it, I'd be less likely to want to do that. That's how people work. + the community can check at the moment. That point is no different.

    This is a completely ignorant statement. Which is more harmful, a keylogger or a trojan horse that shuts down your computer every now and then? Which is less noticeable? The answer is keylogger to both of those. You'd notice your computer shutting down pretty quickly, I'd imagine. With a keylogger, you might not notice until you accounts have been stolen, card details used for fraudulent payments, etc. Slightly more harmful, if you ask me.
    garbagemule likes this.
  26. Offline


    Not less security than now, just re-read what has been said.
    Then not significatly slower checks for full reviews:
    • Current case: reviewer A would take Ta long for his review, and reviewer B would take Tb time long.
    • Double check case: reviewer A and reviewer B start their review. The time of the double check review is max(Ta, Tb), which makes no big difference assuming efficiency of BukkitDev members contain no big gap between them.
    <removed by admin - no need to start flaming>

    And I've already explained I wasn't talking about that. Might be due to my bad english but whatever I already rephrased:
    By "pressure" I mean source opened to the world, none would want to expose its tricks (or really few).

    Because all what you state is perfect. Any open occasion is good to express rage isn't it? I may not have used the best words, I should have imagined you'd make a
    reply to it instead understanding that I meant that the likely null probability of this is by far affordable.
  27. blint66 I think you've missed the point there :)
    Let's assume that all plugins take an hour to approve, regardless of who approves it, or how large the plugin is etc.

    With a single approval system, 2 developers can approve 2 plugins in an hour, as they both approve one each.
    With a double approval system, 2 developers can approve 1 plugin in an hour, as they both work on the same plugin.

    So regardless of how you want to play it, double checking increases the time, because it's double the workload. So please don't imply that I have trouble with maths - I know enough that "double" means "more" :)
    drtshock likes this.
  28. Offline


    Now AdamQpzm do you need a third explanation or you prefer directly admitting your posts are motived by unwillingness?

    Let's get back to the real topic, again.

    Open-sourceable could have the following attributes:
    • Open-source mode should be a developer's choice. Today's mode must remain for developers that don't want to share.
    • File releases wouldn't be uploads anymore, but a branch/revision number. Could also be a revision download, that would be archived and compressed for further diffs
    • Bukkit platform/BukkitDev team builds itself the file to download from source
    • BukkitDev team will be able to check original source, improving reviewing quality and time consumed
    • A diff between two releases would be possible and would reduce the work needed by BukkitDev, even if full checks can periodically be required to perform just in case.
    • Full checks would need to be made by two members of BukkitDev staff in order to reduce the scope of the risk in case some malice slips-in.
    This counterpart wouldn't be that costly considering the adapted bad case scenario mentioned before:
    Let's take a period of five releases:
    • First plugin check: double full check
    • Releases 2, 3, 4 and 5: differential (fast) check
    • Release 6: double full check
    • Differential checks
    • Etc...
    Based on a medium size project, let's assume big changes each time: 50% of total files impacted.
    Time gained: (-1 + 4 * 0,5) / 5 = 20%

    We're talking about 20% gain even in a very bad case scenario, with double checks on full reviews that even guarantee better security than ever.

    So now, what do you guys think?
  29. Offline


    There's the random numbers out of your ass again. Stop trying to quantify the time spent on file approval by considering nothing more than the number of affected files in a diff, it's ridiculous and ignorant. Clearly there's more to it than that. All of your variables are based on speculation and 3rd grade maths, so stop trying to make a point with it - you can't.

    You're STILL completely ignoring anything that's been said to you. I suggest you go back and re-read the posts until you understand them.
  30. Offline


    Not at all. With the current system, there is no "safety net". There is no reasonable assurance that the jar that was uploaded before the current one being checked is even remotely the same code. This encourages more diligent reviews. With the proposed solution, you already assume the code before has barely changed. You can see the previous code history. You have no reason to be as diligent because the process around reviews has encouraged you to be lazy. This is not a black and white world where we can expected our staff to be perfect, so the processes in place have to account for human error, and definitely shouldn't encourage human error to compromise the goals of the system.

    There you go again, dismissing valid reasons that you cannot counter as invalid limitations. You cannot just say "I don't agree, therefor your reasons are invalid". While you may not understand the reasoning, despite the explanation, it is rude to dismiss those reasons as invalid.

    Once again, claiming to be the authority on what should happen, and how much the community can afford for amount of malicious content on BukkitDev? Was that expertise gained in the entire 2 1/2 months you've been a member of this community? You are making grandiose claims and talking on behalf of this community, a right you've neither earned, nor been given except by yourself. Take a step back and stop assuming you know what is best for this community.

    You are making giant leaping assumptions about how your system would work. You've just given a perfect scenario and stated it's how things will normally occur. What happens if someone else is not around to handle approvals at that same time? How do you designate between files that have been reviewed once, and ones that haven't been reviewed at all? How do you ensure that the same person doesn't accidentally handle both reviews of the same file? You would need a new system, one that does not currently exist, to handle this kind of multi-queue setup. Who prioritizes between the queues? What if there is only one person around for a weekend to handle reviews? Your system is more complex, more time consuming, and would lead to slower reviews, and again, lazy reviewing ("Oh, Reviewer A already handled these, I'll just gloss over the file, its probably fine."). If you split the team, which is already pretty small considering the vast amount of work to be done, you lose overall system speed. Security wouldn't improve, nor would approval times.

    Unless you force everyone to use Open Source, and force everyone to use this in house build server, you only gain two ways of handling approvals. Again, you do not gain approval speed, nor would open source encourage our community to contribute any more to the general safety BukkitDev provides. Nothing is stopping people, right now, from contributing to checking open source plugins for malicious code, so to suggest that it would magically happen under your system is a preposterous assumption.

    You made a logical fallacy, one of many you've made in these posts of yours and got called out on it. Stating that just because someone isn't reported means its not a problem is ignoring the very problem you hope to address with your "solution". However, instead of admitting you were wrong, you get mad at the person who called you on your poor attempt at making a point? What a wonderful way to have a discussion. So far, you ignore, belittle, and berate those who disagree with you, while repeating your ill guided ideas over and over again in hopes someone might see things your way, despite the facts and reasoning contrary to your view. If you cannot counter points with factual statements, resorting to petty comments is only making you look more and more stuck in your narrow, ignorant view of the situation. Aren't you the one who keeps repeating over and over we should have an open mind? Yet when you're presented with the same opportunity to listen to others, you bury your head in the sand and close your mind to anyone's idea who contradicts yours. You should take your own advice.
    Of course, this is also the best case scenario, doubling the workload. We're still looking at designing a system to accommodate this fancy new plan, and finding twice as many dedicated volunteers to pull this off to achieve the perfect condition of only doubling the workload.

    There you go again. It can't possibly be that your idea has no merit, right? Instead of attacking those who disprove your wildly inaccurate claims, you could try to counter them with statements that haven't been proved invalid.

    I'll keep this in point form, since I've already stated this before.
    • Still need to handle reviews the old way as we cannot force people into Open Source.
    • Branch/Revision number is meaningless and in no way improves review time
    • Code still needs to be checked, so again does not improve review time
    • Being able to read the original source does not improve reviewing quality (decompilers are a wonderful thing) and would not decrease the time.
    • A diff between the two has already been ruled out. See my posts above about how this would lead to more chance of malicious files being approved and not caught.
    • Two full checks would be dubious at best to reduce the chance of risk, and doubles the workload at best.
    I assume you are just ignoring my responses at this point because this is yet another long post and you are unable to counter my points with facts, hence why you repeat them over and over again. So you've made the approvals faster, so what? You've increased the risk of malicious files getting approved to do so (if you want to see how, read this post again, and all my posts before it). You completely miss the core reason BukkitDev exists, all so you can save a few hours in approval time. When you can come up with an idea that doesn't double the workload on an already overworked group of volunteers, allows for approvals to be as fast as they currently are, and doesn't compromise the safety of the system as it exists today, feel free to propose it. This idea of yours doesn't match that criteria. You cannot judge what % of malicious files on BukkitDev is acceptable because you do not answer to the community. You would happily risk the safety of the system all for the selfish goal of getting your files approved, while those who consume the content of BukkitDev bear the brunt of your decisions. How open minded of you.

    You're talking, at best, a 20% gain in review speed, with at least a 100% increase in workload, for what will not amount to better security (as proven already by my previous comments you so blindly ignore).

    You keep repeating this over and over without acknowledging the flaws I point out. Its unfortunate you can't debate the points, but blindly ignoring people who point out the flaws in your plan gets us no further ahead than when we started. Its too bad, really. I keep hoping someone will come along and come up with an idea we haven't already considered numerous times, and a means to implement the idea that will actually see a ROI in less than 5 years. blint66, you do not even know what is the reason approvals take so much time. You have yet to identify the actual problem, which leaves you wholly inadequate to solve said problem, but your ego has left you unwilling to even ask the question. However, since you have refused to set your ego aside and even ask, I'll leave you wondering. I'm done. Enjoy.
Thread Status:
Not open for further replies.

Share This Page