LWN: Comments on "RPM Fusion, wiki defacement, and bug reporting"

RPM Fusion, wiki defacement, and bug reporting

marcH — Tue, 12 Aug 2014 08:24:48 +0000

I think there is some difference between "official" and "plausible public". At least *I* usually make such a difference!

RPM Fusion, wiki defacement, and bug reporting

derekp7 — Mon, 11 Aug 2014 23:36:08 +0000

But that doesn't keep someone from creating a new wiki page (or adding to any other plausible public page) false installation instructions.

RPM Fusion, wiki defacement, and bug reporting

mathstuf — Sun, 10 Aug 2014 01:09:27 +0000

Oops, didn't check the context; thought this was in reference to the EU's "right" to be forgotten stuff and Wikipedia.

RPM Fusion, wiki defacement, and bug reporting

mathstuf — Sat, 09 Aug 2014 20:39:01 +0000

I think what is being discussed here is deletion from the database, not just the current revision.

RPM Fusion, wiki defacement, and bug reporting

fn77 — Sat, 09 Aug 2014 05:27:25 +0000

Then can I suggest putting a big red warning on the main page?

RPM Fusion, wiki defacement, and bug reporting

fn77 — Sat, 09 Aug 2014 05:23:30 +0000

I'm interested too, but just opening this site:

https://lists.rpmfusion.org/

I get a SSL error:

[...]
You attempted to reach lists.rpmfusion.org, but the server presented a certificate issued by an entity that is not trusted by your computer's operating system. This may...
[...]

Whatever, got subscribed on sysadmin and the confirmation email went on the spam bin at gmail. Confirmed that, other steps for me to follow?

RPM Fusion, wiki defacement, and bug reporting

sitaram — Tue, 05 Aug 2014 09:21:07 +0000

You're right I misunderstood what you said

But deletions can be reverted just as easily as changes to text, so I'm not sure if the end result would be any different than what it is now.

RPM Fusion, wiki defacement, and bug reporting

marcH — Tue, 05 Aug 2014 07:51:46 +0000

> ... where something has been around since 2012 and not fixed. That is what I meant when I said "Considering the history of ignored issues".

I don't think you understood me: I suggested to *delete* this information from the insecure and hackable wiki. Strip the several years old band-aid.
That should be painful enough to attract attention.

RPM Fusion, wiki defacement, and bug reporting

shalem — Mon, 04 Aug 2014 07:26:53 +0000

Awesome! Thanks for volunteering.

RPM Fusion, wiki defacement, and bug reporting

sitaram — Mon, 04 Aug 2014 06:32:30 +0000

normally, you'd be right, but I'm also considering the example in the original article where something has been around since 2012 and not fixed.

That is what I meant when I said "Considering the history of ignored issues". Clearly your rationale doesn't apply, and that if you leave it to the "don't do anything rash" camp it just devolves to "don't do anything".

RPM Fusion, wiki defacement, and bug reporting

marcH — Mon, 04 Aug 2014 06:26:11 +0000

> They need to prioritise. I have no idea what *else* they do, and I am sure it is a lot, but this kind of issue must come first,

... and one effective way to prioritize is NOT to do something quick/dirty/insecure/short-sighted/etc. In this example, it's most likely that someone will volunteer to implement something correctly if this important information is not published anywhere. As it stands almost everyone (but Churaev) must believe that the wiki is either secure or "insecure by design".

I find that the "short on manpower" (and very valid) argument is never good enough to justify doing something very quick and dirty and damaging - of course unless you are *paid* to do it by some mad deadline.

RPM Fusion, wiki defacement, and bug reporting

jdieter — Mon, 04 Aug 2014 05:21:56 +0000

Well, seeing as I'm already in the middle of all this, I'm volunteering. See https://lists.rpmfusion.org/pipermail/rpmfusion-developer...

RPM Fusion, wiki defacement, and bug reporting

sitaram — Mon, 04 Aug 2014 02:08:39 +0000

Considering the history of ignored issues, I'm totally on Churaev's side on this.

As for the comment that rpmfusion lacks manpower, that is common everywhere. They need to prioritise. I have no idea what *else* they do, and I am sure it is a lot, but this kind of issue must come first, even if the latest update to vlc (to use a totally not-random example) is a little delayed.

As of August 2nd, there appear to be some "ACLs" added. It would be interesting to know how much effort this was, and if not much, why it was not done as soon as Churaev first "defaced" the page.

RPM Fusion, wiki defacement, and bug reporting

marcH — Sun, 03 Aug 2014 21:56:45 +0000

> If you actually want to *fix* the problem, then suggest some concrete solutions.

Like for instance... publishing public keys and other critical information anywhere but on a completely insecure wiki? The most basic (and free) Google doc looks far more secure than this. It does not look like the wiki page should have been reverted, it should rather have been deleted!

RPM Fusion, wiki defacement, and bug reporting

Tara_Li — Sat, 02 Aug 2014 23:39:46 +0000

Sure - but I thought most Wikis had a way to lock certain pages to block editing, and ones with particularly critical information, such as pointers to the GPG keys and the repo URLs would be high on the list of those that I would have blocked for editing in the first days of the project.

RPM Fusion, wiki defacement, and bug reporting

shalem — Thu, 31 Jul 2014 07:58:28 +0000

The biggest problem rpmfusion has atm is manpower, esp. at the infrastructure / sys-admin side of things. If anyone wants to help out and become a sysadmin (and has a proven track record in FOSS) I'm sure help would be very much appreciated.