gregh

Rather than getting into debating good and bad “intentions”, as far as I can tell, the repackager did nothing wrong. Did she strip your copyright notices from your source files? If not, no GPL violation. (Note I haven’t actually checked this, but I do note in the email that you quoted that the person directs you to look at the CSS file where you are credited.)

In any case, it seems ridiculous releasing a theme under the GPL. The GPL is for software. How many lines of code were in your theme? I would have thought that one of the Creative Commons licenses would have been a better fit for your themes.

As for your use of the copyrighted movie image without permission, I’m afraid that saying that fan sites use it, or that you don’t intend to make money from it, or that you thanked them profusely for it in your README file etc won’t protect you in a court of law. The only thing that will protect you is written permission from the copyright holder. I presume you haven’t asked for such permission because you know that they won’t give it to you.

Yes, why do you ask? I was agreeing with you.

Yes, I know they’re on the Dashboard, but I shouldn’t have to log in to my WordPress install just to make sure there are no security bugs waiting to be fixed…

After a one month delay, my ticket (https://trac.www.ads-software.com/ticket/2772) was closed as “worksforme” with the comment “We don’t use the list much, but the subscription part works.”

How, then, do I subscribe? I enter my email address in the box and hit the “Join” button; I am then shown a page which says, “You’ve been subscribed to the list. Thanks!”

But I’ve never, ever received a release announcement. As I’ve already noted, with buggy software like WordPress, it’s important to receive timely notification of releases because they may contain important fixes for security holes.

Well no replies after one week, so “bumping” this one up to the top again. And the bug ticket was opened three weeks ago with no comment or change from anyone. Do the WordPress team look at newly opened tickets at all?

Can someone, anyone, confirm that they’ve been able to join the announcements list? It doesn’t take long to add a “works for me”, or “broken for me too” comment.

https://www.php.net/manual/en/control-structures.alternative-syntax.php

For reference, here is the thread:

https://comox.textdrive.com/pipermail/wp-hackers/2005-December/003670.html

My point wasn’t about adding “any feed” or even about flexibility; what I really meant was I don’t like seeing the Dashboard cluttered up with birthday announcements for people I’ve never heard of when the heading is “Other WordPress News” (not “News About The Personal Life of Some Guy Who Is Involved in the WordPress Project”).

A few points:

1. I am not interested in philosophy.
2. I am not a WordPress programmer; I’m a WordPress user.
3. You claim to have created uploads/12; you were supposed to create uploads/2005/12 (etc).
4. If you had read the thread you’d realise that you need to set permissions to 777 on all those directories, not 766 (why did you choose 766 anyway?).
5. Your attitude is extremely annoying.

I don’t think “wp-content/2005/12” exists, seeing as WordPress is trying to create it. It wouldn’t try if it already existed. You have to create it and upload it yourself. And it needs permissions of 777 or the Apache process won’t be able to write to it.

You’ll need to create and upload not only 2005, but the subdirectories as well (1, 2, 3 etc). Same for 2006 etc.

When safe mode is turned on, PHP will refuse to move the uploaded file into the appropriate directory (ie. wp-content/uploads/2005/12/) unless the directory is owned by the same user as is running the script.

In your case, for some reason your upload directory is owned by user 1301 but your admin-functions.php script is owned by user 30. Even if you have totally open permissions (777) PHP will refuse to move the file until you make the uids match (using chmod).

Presumably you could also get this to work by uploading the scripts and the directories using your FTP client; that way they’d all have to have the same uid (ie. the uid of the user you’re logged in as via FTP).

In order to get the cache working under safe mode, I’ve had to chmod all of the directories to 777, as well as changing the ownership of the wp_object_cache.lock file to apache:apache.

Looks like I spoke too soon about file uploads working. I get the failed to open stream: Permission denied error on attempting to upload. I tried setting the suid bit on the directory (chmod 4755) but got the same error. So I set the perms back to 0755 and set the ownership to apache:apache and got SAFE MODE Restriction in effect. The script whose uid is blah is not allowed to access error. Seems the only way I can get uploads to work is to make the directory permissions 777.

I looked into using ACLs to grant perms only to the Apache user/group but support for ACLs is not available on my server.

So looks like I have a choice between two kinds of security hole:

1. Either I turn off safe mode which means that any potential security hole in WordPress can have a greater impact; and apart from that I don’t like turning off safe mode for any of the virtual hosts on the server because of the “shared server” security issues.

2. Keep safe mode turned on, but leave a whole stack of world-writeable directories around the place, which is in itself sloppy security practice.

I now suspect that the reason the cache files are being created is because the directory permissions aren’t 777 (same problem: sloppy permissions).

Ok, so I tried out what you suggested here… creating the directories, setting the appropriate ownership and permissions, and then turning safe mode back on. The results aren’t the best. Anyway, first of all, here’s what I did to set up the directories and set the perms:

# world-writeable directories are bad
chmod 755 wp-content
cd wp-content
chmod 755 cache
chown -R me:me cache
cd cache

# full salted directory path not shown
chmod 755 c4ca4238a...
chmod 755 userlogins users
cd c4ca4238a...
chmod 755 category options pages
cd ../..

# set up 10 years' worth of directories
cd uploads
for YEAR in 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
do
for MONTH in 1 2 3 4 5 6 7 8 9 10 11 12
do
mkdir -p "${YEAR}/${MONTH}"
done
done

cd ..
chown -R me:me uploads
chmod 755 uploads

Now file uploads work, but strangely:

-rwxrwxrwx 1 apache apache 13364 Dec 28 16:17 P.jpg*
-rw-r--r-- 1 apache apache 2205 Dec 28 16:17 P.thumbnail.jpg

Note that the uploaded file is created with permissions of 777, but the thumbnail generated by WordPress has permissions of 644. In both cases the files are owned by the Apache user/group. There are no problems deleting these files. I am a little surprised that the created files are owned by apache:apache, because my reading of the safe mode documentation — https://www.php.net/features.safe-mode — leads me to believe that created files should be owned by me:me (ie. the owner of the scripts) even though created directories are owned by the Apache user/group. By using the phpinfo() function I’ve been able to confirm that safe mode is definitely enabled in the directory where my WordPress install resides; and my WordPress scripts are all definitely owned by me:me.

The cache, on the other hand, doesn’t seem to work at all. I tried clearing out the cache and no matter how many pages I visit no new object files are written to the cache.

Finally, for the weirdest part of all; with the wp-content permissions set to 755 I couldn’t view my weblog at all! The admin pages worked, but all the public pages returned zero byte non-HTML pages (that is, my browser attempted to download them instead of displaying them). I set the permissions back to 777 and the problem went away. Then I set them back to 755 and everything continued to work. I suspect that there is something fishy in the cache code. I am going to take a look at it.

Agreed. It would be useful.