Hi!
User Details
- User Since
- Oct 25 2014, 1:53 AM (449 w, 1 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- Bawolff
- LDAP User
- Brian Wolff
- MediaWiki User
- Bawolff [ Global Accounts ]
Fri, Jun 2
I dont really understand. If the rows were legacy encoded as windows-1252, why would we convert UTF-8//IGNORE to UTF-8.
Wed, May 31
I think without the patch the error would still happen just much more silently but still just as broken. I dont think its an improvement to show a blank page
Tue, May 30
Happy to sign a new nda if neccessary.
Mon, May 29
Thu, May 25
Sun, May 21
Sat, May 20
There are also opportunistic limk updates of the page is "dynamic", but yes it is limited.
Fri, May 19
You can definitely already do this - e.g. make the category used depend on the current time or something. It does seem like this might make the problem worse though.
So I was chatting with @Yug at the hackathon about this. He was hoping this could be reconsidered.
I dont think it falls afoul of that as long as it is reflecting DB state (current contents of categorylinks) and not currently parsed page.
Thu, May 18
Tue, May 16
Extdist is also using replica currently.
Mon, May 15
The main reason i would argue for iframe sandboxing is that it ties it to the browser same origin policy.
Sun, May 14
Sat, May 13
I've been experimenting a little bit in this direction with https://www.mediawiki.org/wiki/Extension:Monstranto
It would be the same parser output since it would come from the parser cache
That seems much simpler. You'd loose interactivity of graphs, but let's be honest... the interactivity-part has been an 8 year long nightmare. Maybe its time to put that to bed and accept defeat. I'm sure it would piss off many people, but the entire organization is over committed, choices unfortunately have to be made.
Fri, May 12
Are they? Something like {{Map with marks}} seems entirely compatible with a specification JSON template approach to me. (Migrating existing graph templates would certainly be unpleasant work, though.)
The specification would be less flexible - right now you can use templates or Lua to make the specification dynamically depend on the parameters of the graph, this would become impossible. Other than the data and maybe a few other predefined modification points, specifications would be static. Not sure if this would significantly impact real-world usage.
This seems like it would be easy to add as an extension (as long as it is just config and not loading other extensions). I'm not sure that i think it makes sense in core, or at least not until it has a proven track record of people using it.
Mon, May 8
Sun, May 7
Sat, May 6
I think a simpler solution to the problem of Composer installing compatible extensions is for extensions to increment their major version number when they drop support for a version of core.
However, this seems like what FallbackSlotRoleHandler is supposed to do.
Fri, May 5
Sorry, i just realized i misunderstood how this feature worked, and I don't think it is a viable solution to the problem it is trying to solve. I still stand by my comment about code-owners being a path that we as a community should move forward on. However i no longer object to this feature being removed, as i don't think it is a viable way forward to the versioning problem, since using it means you cannot install the extension independently of composer, which is kind of critical to how the majority of people use composer. So consider my objection withdrawn.
I don't know how technically feasible it is but I think it should be possible but out of core, into a dedicated repo that could have core as a submodule.
May 4 2023
So, I sort of had a change of heart about this task. (To be clear because it is confusing, by this task, i mean removing support for depending on the fake mediawiki/mediawiki dependency in composer)
May 3 2023
Historically i think the concern was you load a normal page as a csv file, parse out the edit token from the html source, then leak the edit channel via a side channel to an attacker. [Otoh good luck executing csrf style attacks on a modern browser, so maybe that specific scenario is less relavent now, although similar scenarios may still matter]
May 2 2023
May 1 2023
I mean, for any dynamic parser function, you'd be kind of hoping that you retrieve the same parser output. {{NUMBEROFARTICLES}} is commonly used as a very bad pseudo-random number generator on enwiki. It seems like you would often retrieve different parser outputs and the graphs wouldn't match if they used dynamic parser functions, unless i misunderstand the plan.
Apr 29 2023
Actually, i just read:
Apr 28 2023
What does "temporarily" mean here? It seems unlikely anyone is going to come around and fix the extension any time soon. If its going to be permanent we shouldn't mislead people.
Apr 27 2023
I mean, traditional in the sense of loading it via an URL. It would still be sandboxed. That would make it behave as if it were from a different domain on almost all browsers where we actually load Javascript
traditional iframes (results in a bunch of extra requests + need to pass state, which imposes GET length constraints)?
Apr 26 2023
The fact that there has been close to no issues in 20 years, where Graph has had many issues even before the current one.
Apr 25 2023
Im not sure we should. This sounds like useful information to people auditing extensions or developing extensions, but im not sure it is useful to average end user.
I think recent events further suggest that migrating to graph would probably not be a good maintainability move.
Apr 23 2023
It is likely you had a system update, and the font was added to your system. It is likely that this will depend on what operating system you are using. That or you installed the font locally.
Apr 21 2023
After all this done, are you going to publish the full explanation about the security breach
Apr 20 2023
T182536 has been around for more than five years
Apr 19 2023
In addition to fixing the underlying issue, i think this bug shows that vega really should be rendered into an iframed sandbox.
Apr 18 2023
With all due respect to everyone involved, i really think its not ok to disable something not actively being exploited [i assume, i dont know), and is used in main namespace for real articles, without giving at the bare minimum a day notice (wikitech-l + mass message VP) so users can fix articles. Even if this was actively being exploited (or is likely to be upon announcement, has public PoC, whatever) i would expect comms to fast follow disabling. At least inside of an hour.
In addition to this being essentially duplicated info (that is often wrong as in many extensions its only used in debug mode so typos go unnoticed), i feel like this really doesn't make sense to specify in extension.json.
Apr 17 2023
Has anyone told the affected projects that this will happen?
I kind of wish there was basically some sort of hook here where i could combine things in arbitrary ways. I don't think a few predefined options is ever going to be sufficient.
Apr 14 2023
Apr 13 2023
Note that all browsers on iOS use WebKit engine (Chrome, Opera and even Firefox). So I doubt Puffin Browser can do anything about what they support. This is due to Apple policy which bans browser engines on their store. I guess most devs know that, but every browser on iOS is a skin over Safari (mostly).
As quite a few Wikimedians experience issues with IP blocks and related it might be useful to have a shared hybrid session about this problem and work on possible paths to advance it.
Apr 12 2023
Why didn't we just add .map to the whitelist?
Apr 10 2023
do you need all of these permissions still?
Apr 8 2023
Some information is public. Private data will not be released.
Apr 7 2023
Commons already runs tests on files via bots to detect embedded info, it wouldn't surprise me if they might already detect this - although previous work was more about detecting multi-gb movies embedded in jpg files so maybe not.
Apr 5 2023
The webpack vulnerability is pretty silly. It is basically - if an attacker can modify your source code, then they can run arbitrary code.
Just noting because there were some user complaints on project:Support_desk, and it doesn't seem to be mentioned here explicitly - Firefox 52 is the last supported version on windows vista, which is no longer supported.
[Making public since resolved]
[marking as public since resolved]
Apr 4 2023
@Mstyles Can this be added to next extension security supplement?
Apr 3 2023
Apr 2 2023
I guess b16734996ad55b9463 broke this.
This seems to have regressed, but given how old this bug is, i just created a new one - T333776 instead of reopening this one