We’ve noticed an influx of new entries in the BlackBerry Trac that are hacky/spammy. Example:
https://blackberry.trac.wordpress.org/#no1
https://blackberry.trac.wordpress.org/ticket/263
Can we block this from happening for the existing bad accounts posting and also prevent it from happening further? The BlackBerry app is also dead (for several years now) so we can freeze the entire site or get rid of it entirely.
It’s getting pentested: https://gsoc.trac.wordpress.org/ticket/386
Can we make it read-only, and if not, then maybe back it up and shut it down, or put it behind proxy auth or something? It’d be nice to preserve the content for history, but it’s probably not worth maintaining anymore, and definitely not worth cleaning up after pentesters.
I need to get theme commit access for @ianbelanger to manage work on the default themes. Our most recent two theme committers have had to step back and they worked with him directly to do some training/hand off. I will make sure to share the following documentation with him as well:
This is a #prio2, but would be great to get sorted for work on WP5.2.3 and WP5.3.
Currently the nginx rules for the theme directory includes a similar to the following, can we please remove it, as it breaks access to URLs that shouldn’t have a trailing slash, such as https://wordpress.org/themes/sitemap.xml
There should already be a handler in the PHP environment to add the trailing slash if it’s missing.
location /themes/ {
# Add a trailing slash to all themes
rewrite ^/themes/([^/]+)$ /themes/$1/ permanent;
}This is a known issue, but it seems like it’s gotten significantly worse in the past ~6 months, to the point where it’s disruptive to workflows, and would delay promptly recovering from bad deploys.
Here are some timings from my WordCamp.org sandbox using, using themes.svn as a baseline.
/wp-content/themes ( 10
svn:externals tothemes.svn)
$ time svnup
…
real 0m0.313swp-content/plugins ( 27
svn:externals toplugins.svnitems, 1 tometa.svn)
$ time svnup
…
real 3m29.532s$ time deploy-wordcamp.sh
…
real 4m44.074s
With a deploy taking almost 5 minutes, there’ll be a lot of extra/unnecessary downtime if we ever need to revert a bad commit and re-deploy.
As per previous discussions, can we please remove the Trac Caching that strips the Set-Cookie headers from Trac ticket pages?
As mentioned, this causes failures to comment on tickets – https://meta.trac.wordpress.org/ticket/4360
As discussed, you’ll find a hacky Trac plugin that attempts to avoid setting useless Trac cookies in https://wordpress.slack.com/archives/G02QCEMRY/p1554790742034300?thread_ts=1554340318.022800&cid=G02QCEMRY but it’s mostly untested and may not work as needed.
The Latest trac plugin is in https://gist.github.com/dd32/e1a6e434cb9b5721cc086e51751f8c44 and has been tested well on a standalone trac installation.
The plugin does several things:
– Prevents Cookies being sent on anonymous pageviews
– Prevents anonymous sessions being saved to the DB (as there’s no such thing anymore)
– Blocks access to /prefs for anonymous users
– Expires all trac_* cookies after the user is no longer authenticated, such as to remove the trac_form_token cookie.
Hello, can you please set up proxy access for @tobifjellner. He’s a polyglots mentor.
The public key is:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAuf3oli0Y3f1Ym36R/NlcuArgNETjzOdlX4q0dj5i56s80Pp55TdbxU3D0H4hZcVOtacYdkcbrS7Byg/0kfMi0RGBEkKgMv4lBewwHxaegWmkTl38DROssioatAWAOEER9EiMTF6cChM68eolLo6xc7ju9K0gn9Mg98hrbr44f22/BATTDpKGefziCOGHSWxjK8juoD/sKmim/XNLK77/I7KNDNv2qxO3hwtHot5/R2+QfU//1zusJx9OFrJ6mriDENurvGWwXf88QcRkjnQxFUfu+NZLT9x2hR3RsKiG3copmWyVZ7OHFShiizlzvji2N9YDBpFUvBrB6VouIAIDZQ== rsa-key-20190620Thanks!
#prio2Hi! As per a discussion with @andreamiddleton can myself and @tellyworth please have the WordCamp role applied to our sandboxes?
This is to aid in support for WordCamp Europe this year if any unexpected things come up, and ongoing work we do that crosses over into that area.
When using the proxy created for me in 2017, I have access to the dotorg SVN, but for some reason I’m still getting “403 Forbidden” when trying to access dotorg Trac to view changesets.
@pento tried to fix this at WCEU last year, but something was still missing. Initially we assumed that capital letters in my username (SergeyBiryukov) might be an issue, but changing it to lower case didn’t help, and the change was reverted.
He suggested submitting a Systems request to look further, which I’m doing now.
If someone could make my dotorg Trac access work, that would be grealy appreciated 🙂
As per https://meta.trac.wordpress.org/ticket/4245 can we please enable a HTTP -> HTTPS redirect for pingomattic.com that keeps the REQUEST_URI intact?
