I'm frustrated that another release is done with security fixes and when I check Github, I have no idea what files were fixed for the exploits. I cannot do upgrades immediately. My site breaks running the script because my database is too large for commands and the upgrade script will timeout.
Can you PLEASE PLEASE PLEASE at least after you release an upgrade make security fixes at Github visible?
This is just frustrating. You tell everyone there is a vulnerability now and you don't tell anyone what the fixes are!
CHANGE YOUR POLICY ON THIS! It's antiquated and quite frankly DUMB.
And yeah, I'm pretty much ticked off about this because I've mentioned the issues and I'm tired of every update of MyBB being a nightmare.
I think telling what has been patched for security issue will let others use those vulnerabilities to mybb forums which weren't upgraded.
We are currently discussing a modification to the release workflow to include releasing a second zip file containing our internal .patch files that we create for security patches. We should agree on this tonight I hope and have the packages available in a couple of hours.
Providing these patch files should help everybody whether their board is big or small as patched are usually small and self contained and usually don’t need database changes or anything, but may require template changes. In the case of template changes being required, you would need to read and understand the patch files to know what needs done.
Euan, do you have the security fixes at Github? I would think just like any other bug report you could have them there under a SECURITY tag. I assumed that's what you already did but kept the tags hidden.
How it is now is just fine imho for bug fixes.
https://github.com/mybb/mybb/issues?q=is...e%3A1.8.20
I go there, I see what's fixed in the release and can decide what bugs I want fixed.
If you just do a SECURITY tag and separately link to them in the blog post that's more than enough for others to get from Github the appropriately changes.
And again, the team is having an INTERNAL discussion about the process where the community doesn't get any input until AFTER it's implemented. No chance to consider options, come up with different ideas, or participate in the process. That's a continued problem as well. IMHO that's a real shame that the community is often not involved in this and why we often feel distant from the project (or at least I do).
(2019-02-28, 09:38 PM)labrocca Wrote: [ -> ]Euan, do you have the security fixes at Github? I would think just like any other bug report you could have them there under a SECURITY tag. I assumed that's what you already did but kept the tags hidden.
How it is now is just fine imho for bug fixes.
https://github.com/mybb/mybb/issues?q=is...e%3A1.8.20
I go there, I see what's fixed in the release and can decide what bugs I want fixed.
If you just do a SECURITY tag and separately link to them in the blog post that's more than enough for others to get from Github the appropriately changes.
And again, the team is having an INTERNAL discussion about the process where the community doesn't get any input until AFTER it's implemented. No chance to consider options, come up with different ideas, or participate in the process. That's a continued problem as well. IMHO that's a real shame that the community is often not involved in this and why we often feel distant from the project (or at least I do).
No, we manage security patches as threads here in the forums, with the patches posted inline in posts in the form of
.patch files. GitHub provides no facility for private issues or tags or anything unfortunately (our current workflow is a bit of a nightmare because of this deficiency in GitHub...). We keep hoping GitHub might release something like private pull requests or private branches or something to ease this.
Our internal discussion on this started when you created this thread and went like this:
Quote:Me: Should we share the patches?
Kawaii and Devilshakerz (Devilshakerz co-ordinates releases most of the time): Yes
Me: Ok
That's the limit, and was all on Discord as a quick fire question to ensure I hadn't missed some stupid reason why we shouldn't share the patches.
Most of our major discussions are public now, with the only private discussions being about how to handle things like account deletion requests, staff applications, team members going on holiday or leaving, how to handle moderation issues, etc. No development conversations (about from co-ordinating security patches as mentioned above) happen privately. It's all either in a public forum, in GitHub or on Discord.
Devilshakerz even reminded me that the patches are already publicly available! If you go to the following page on GitHub:
https://github.com/mybb/mybb/releases
Every release using our current workflow is posted as a release on this page. The ZIP file you want is called
build_VERSIONCODE.zip (eg:
build_1820.zip). Inside this ZIP, look inside the
input/patches folder. All of the security patches are available in there as
.patch files.
This
input is used when we run our documented build process:
https://github.com/mybb/mybb-build
Quote:No, we manage security patches as threads here in the forums, with the patches posted inline in posts in the form of .patch files. GitHub provides no facility for private issues or tags or anything unfortunately (our current workflow is a bit of a nightmare because of this deficiency in GitHub...). We keep hoping GitHub might release something like private pull requests or private branches or something to ease this.
Then can I suggest that the week of release you put all the fixes up on Github even if it's public? My desire would be that you put them up on Github the moment you have them patched even if a release isn't coming for months. IMHO it's more important to release fixes for exploits in a timely manner than just about anything else.
Also is the patch file compatible with the Patches Plugin?
https://mods.mybb.com/view/patches
And are you guys saying you don't have a paid Github for the organization? They do have private repos at Github.
Quote:Every release using our current workflow is posted as a release on this page. The ZIP file you want is called build_VERSIONCODE.zip (eg: build_1820.zip). Inside this ZIP, look inside the input/patches folder. All of the security patches are available in there as .patch files.
I don't see it. I just see some Docker instructions there. I don't use Docker nor will I. So how do I get the patch file with only the security fixes?
EDIT: Found it based on our previous discussion about this.
https://github.com/mybb/mybb/releases/tag/mybb_1820
Would be nice if that was included in the blog post for releases if there is security fixes.
(2019-02-28, 10:48 PM)labrocca Wrote: [ -> ]My desire would be that you put them up on Github the moment you have them patched even if a release isn't coming for months. IMHO it's more important to release fixes for exploits in a timely manner than just about anything else.
Even though I agree with your regarding the patching of security issues as an important matter, I think it will be incovenient for the vast lower group of administrators who follow neither the repositories nor the blog posts but mostly just the released package updates.
We do have a GitHub enterprise account with private
repositories, but that doesn't give us private
tags or
branches. A private repository is completely private and can only be accessed by members of the organisation (and we pay based on how many members there are) and there is no mid-level between "completely hidden" and "completely public".
I don't know if the patches work with the patches plugin, as I've never tested it. They do work with the standard UNIX patch tools though:
https://en.wikipedia.org/wiki/Patch_(Unix) - you should just be able to patch from the command line on any UNIX server
We've discussed the way we manage security reports before. Immediately putting fixes on GitHub without a proper release will mean that security bugs are public knowledge before 99% of users upgrade. Most of our users don't even upgrade to full releases as soon as they're released - do you really think people would keep on top of security patches? Because I don't. Additionally, some of the fixes occasionally require database or template changes - these would require users to apply them manually if not part of a full release as the upgrade script only works with full version upgrades.
(2019-03-01, 02:14 PM)Euan T Wrote: [ -> ]I don't know if the patches work with the patches plugin, as I've never tested it. They do work with the standard UNIX patch tools though: https://en.wikipedia.org/wiki/Patch_(Unix) - you should just be able to patch from the command line on any UNIX server
They aren't compatible with frostschutz's Patches plugin, that accepts files in a proprietary XML format. The best way of applying our patch files manually would be to navigate to the root of your forum directory (i.e.
/var/www/html/forum/) and running
GNU Patch (standard on most Linux systems) like so:
cat /path/to/patch/example.patch | patch -p1