MyBB Community Forums

(2019-02-18, 08:08 PM)someoneBig Wrote: [ -> ]

One big NO for this.....

@labrocca:: I think I understand you well, but please calm down. No matter how many times you are going to complain and no matter what words you're gonna use, it will not change current team, their attitude towards users, their pace of work..... nothing will be changed unless all the members resign or are forced out by project manager. Chris? He gives a middle finger so there is noone supervising current team.

===============

Quote:Of course, we would like to find more people to help

Seriously????? Under another nick, I suggested giving MyBB help, by taking it over and making it developed by team of paid developers working full-time on MyBB. What was team's reaction? I was ridiculed, my posts regarding this were deleted, I was banned.

So, dont LIE that you would like to find new people to help...... when new people showed up (with easy-to-achieve roadmap) you dismissed (litely speaking) offer..... 

I assume your previous name was "devs"? If so, your past offers weren't taken seriously for several reasons:

• As far as we know, you've never made any public contributions to MyBB of any kind (code, issue reporting, code reviews, etc.)
  
• As far as we know, you have no publicly available code or projects related to MyBB to show your experience
  
• You forked MyBB to a private organisation (to which I was invited) almost a year ago and have so far only made one commit out of tree which was a simple update to a README file
  

If your offer is truly sincere and you really have the ability to back your words up with actual action, I'm sure Chris would be willing to hear you out. But we need to have actual specific details and proof that you can walk the walk as well as talking the talk.

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

You’ve wholly misunderstood. I would like to see something here that encompasses the same principle: That is, a vulnerability is hidden until fixed and then disclosed. I did not suggest actually using HackerOne - I get MyBB has no money to do payouts, and that’s not the expectation I want to set - but they’re perhaps the most notorious for this concept.

(2019-02-18, 09:14 PM)Ben Cousins Wrote: [ -> ]

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

You’ve wholly misunderstood. I would like to see something here that encompasses the same principle: That is, a vulnerability is hidden until fixed and then disclosed. I did not suggest actually using HackerOne - I get MyBB has no money to do payouts, and that’s not the expectation I want to set - but they’re perhaps the most notorious for this concept.

We do, in fact, plan to be present on HackerOne or equivalent (although with no monetary compensation) for numerous reasons (centralized index, a reporting platform that's separate from the product in question, a workflow that's compatible and ready to integrate + improved transparency), but it would go together with other organizational changes (1.9 or 1.10 in our case) to make the transition more smooth and to avoid complicating a process that's already in place (e.g. so data related to a specific branch can be tracked on a single platform).
A change that's also waiting to be introduced is switching to CVSS v3 assessments instead of arbitrary risk labels, and with improved git flow we should be able to safely prepare & release hotfixes independently of the standard development track - without the overhead caused by linear git history.
In the meantime we've put up an updated disclosure page, SECURITY.md, and the general security workflow at https://docs.mybb.com/1.8/development/se...-workflow/.

RE information on development status: our metadata tracking (Issues, PRs, milestones) improved enough to be relied upon without cross-referencing with the Community Forums when it comes to 1.8 (same should apply to subsequent branches close to final releases), so it will be much easier to provide links to status pages or listings related to versions, bugs and features in focus at any given moment; the 1.9 status is still somewhat fluid, but once that stabilizes there should be an Issue filter or Project on GH that will allow to replace rough estimates with a specific number of problems that should be addressed before the branch is ready.

(2019-02-18, 09:14 PM)Ben Cousins Wrote: [ -> ]

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

You’ve wholly misunderstood. I would like to see something here that encompasses the same principle: That is, a vulnerability is hidden until fixed and then disclosed. I did not suggest actually using HackerOne - I get MyBB has no money to do payouts, and that’s not the expectation I want to set - but they’re perhaps the most notorious for this concept.

Ah, sorry. I was partially skim reading.

We did actually have an RFC where I tabled the idea of doing exactly this. I've just requested that we make that RFC public (something that we have previously tried to get better at, but which eventually comes down to time constraints once again... ) and after doing so we may end up re-visiting our procedures as the last time we made any changes to the workflow was in July 2018.

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

There are two different types of programs on HackerOne -- bug bounty programs and vulnerability disclosure programs. The former pays out money, the latter pays out nothing. There's no expectation for vulnerability disclosure programs to reward bounties, and it's very clear which programs don't.

https://www.hackerone.com/blog/HackerOne...e-Projects

(2019-02-19, 04:07 AM)Nathan Malcolm Wrote: [ -> ]

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

There are two different types of programs on HackerOne -- bug bounty programs and vulnerability disclosure programs. The former pays out money, the latter pays out nothing. There's no expectation for vulnerability disclosure programs to reward bounties, and it's very clear which programs don't.

https://www.hackerone.com/blog/HackerOne...e-Projects

There you go. That I didn’t know - thanks Nathan!

(2019-02-19, 05:13 AM)Ben Cousins Wrote: [ -> ]

(2019-02-19, 04:07 AM)Nathan Malcolm Wrote: [ -> ]

(2019-02-18, 08:15 PM)Euan T Wrote: [ -> ]Regarding HackerOne or some such for security reports. We've discussed this kind of thing a couple of times as a team. The only thing that's put us off using HackerOne as far as I can remember off the top of my head is that there tends to be an expectation for bounties when using HackerOne - we can't really offer bounties given that we're not making any money or anything...

There are two different types of programs on HackerOne -- bug bounty programs and vulnerability disclosure programs. The former pays out money, the latter pays out nothing. There's no expectation for vulnerability disclosure programs to reward bounties, and it's very clear which programs don't.

https://www.hackerone.com/blog/HackerOne...e-Projects

There you go. That I didn’t know - thanks Nathan!

Ditto!

Thanks for the input Nathan. I'm hoping to make our RFC from last year public at some point this week, in which we discussed using HackerOne and how we handle reports and such. When the RFC was discussed, it seems we decided to postpone using HackerOne until 1.9, but we might well end up re-thinking that one.

(2017-12-18, 07:18 PM)Euan T Wrote: [ -> ]Okay, so how about this as a roadmap for the future:

• Plan for a 1.9.0 release as the next major release. This release would:
  • Bump required PHP vesion to PHP 7.0 in anticipation for the future. [DONE]
    
  • Implement Twig as a template engine. [IN-PROGRESS]
    
  • Introduce Composer to manage 3rd party dependencies and provide autoloading [DONE]
    
  • Introduce the SwiftMailer library to handle the sending of emails, fixing compatibiltiy issues with different SMTP hosts. [DONE]
    
  • Introduce a brand new theme which would be fully responsive and mobile ready. [IN-PROGRESS]
    
    
• Once 1.9.0 is released, work towards the next major version as 1.10.0. This release would:
  
  • Introduce user alerts to the core, alerting users of new PMs, replies to threads, etc.
    
  • Look at introducing other 3rd party components (such as introducing a third party caching library to add more cache drivers, introducing a new query builder to be used whenever new features are added or reworked).
    
    
• Once 1.10.0 is released, work towards the next major vesion as 1.11.0. This release would:
  
  • Bring in conversations as a replacement for Private Messages, and integrate them with the alerts system from 1.10.0.
    
  • Continue introducing other 3rd party components.
    
    
• Once 1.11.0 is released, work towards the next major vesion as 1.12.0. This release would:
  
  • Look at changing the plugin structure to make use of Composer and provide plugins as Composer packages. This would:
    • Allow plugins to easily register classes in the autoloader
      
    • Make it easier for plugins to add new JS, CSS, etc. as plugins would all extend a base class that would provide common funcitonality - much like the 3rd party PluginLibrary project by frostschutz does
      
    • Make it possible in the future to automate the installation of plugins straight from the Admin Control Panel, as all plugins would follow a common structure.
      
      
  • Continue introducing other 3rd party components.
    
    

In the background, as this process happens, we could continuously work on larger refinements and enhancements such as adding a CLI tool to the core, rewriting the ACP to make use of templates, etc. These major additions and changes could be rolled into the next major release (where the middle version changes, such as 1.8 -> 1.9 or 1.9 -> 1.10).

Also of note for this approach is a slight change to how we number versions. Currently, we skip odd numbers and call them development versions. This is pretty odd, and makes little sense when the numbers don't actually get used anywhere in the core. With this roadmap we'd be using verison numbers in a way that makes more sense.

Any more thoughts or comments on the above approach? I'd rather the whole community were settled on an approach and knew where MyBB as a project is heading.

If the majority of us agree with a roadmap like the above (or one based upon this kind of structure with a clear plan of tasks to complete - we are open to changes, so long as it doesn't become a case of the plan being entirely impossible to achieve with 1001 features being added every release), I will write a blog post and start a project (or series of projects - one per version number for the next 2-3 major verisons) on GitHub to get momentum heading in that direction. What I don't want is for us to agree on a roadmap or plan and then have to change direction once again because people have found something else to be unhappy about.

Waiting for MyBB 1.9. In which month of this year will it be released?

When it is ready. And not before.