Re: Fedora TV Submission Form - PHP
On Tue, Jun 17, 2008 at 11:45 AM, Mike McGrath [EMAIL PROTECTED] wrote: On Tue, 17 Jun 2008, Ricky Zhou wrote: I also like the idea of trac or a mailing list for something like this (releng even does something with an email - trac gateway). Even that might have issues if we're pushing large files around. I believe the email just includes a link to the Video URL, not the video file attached to the email. To do this, we planned to create a simple web form that collects the users' data (Name, e-mail, video URL etc)... ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: PHP Security Tweaks
I took a look at pt2 again today and it looks like the php.ini was set back to the default after Ricky and I sorted out the OpenID issues on Monday. Was the more restrictive version causing troubles for someone? I would be happy to look at what was going on - so far we've been able to adjust it to make everything that has been brought to my attention work - but I need to know what broke to see what needs tweaked before rolling this to the production systems. Just let me know what broke and I will look at it again. Thanks! Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: PHP Security Tweaks
On Sat, May 31, 2008 at 11:30 AM, Mike McGrath [EMAIL PROTECTED] wrote: Sorry, I'll set that back to how it was. I moved it to test some strange things that were happening. Cool! Thanks Mike. I wasn't sure if it had caused issues again or not. I was giving it some time to sit on publictest2 without causing issues before seeing if we could push it to production. Thanks! Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: OpenID
On Thu, May 29, 2008 at 9:01 AM, Jeffrey Ollie [EMAIL PROTECTED] wrote: 2008/5/29 Till Maas [EMAIL PROTECTED]: Here is an interesting blog article about security considerations wrt. openid: http://idcorner.org/2007/08/22/the-problems-with-openid/ While I don't have any specific replies to the issues that Stefan Brand points out in that article (I'm too new at the OpenID game), it should be noted that Stefan is the owner of a company that is developing a competing patented[1] technology that recently sold out to Microsoft[2]. However, David Recordon does have a rebuttal of Stefan's points[3]. [1] http://www.credentica.com/patent_portfolio.html [2] http://idcorner.org/2008/03/06/microsoft-acquires-credenticas-u-prove-technology/ [3] http://daveman692.livejournal.com/310578.html I wouldn't dismiss his comments because of who he sold his patented technology to until people on the infrastructure team more familiar with OpenID and the security risks associated with it (I'm not that person either :-) ) have reviewed the article for merit. Stefan does post a follow-up comment to the David Recordon post. It seems people are divided on the security OpenID does or does not provide. It also seems to me an area where if OpenID is implemented there should be some people on the infrastructure team that understand the nuances of any security issues related to OpenID. We may have those people on the team already - in which case hearing their opinion on some of these articles would be useful. The phishing problem isn't unique to OpenID. No, it isn't unique to OpenID - but it is certainly an area we should take into account before implementing OpenID. With all of that said - I like the OpenID idea. And we run other services that have potential exposure to security issues (ssh, just our normal FAS logins, etc) - but we do make efforts to protect those services to the best of our ability to reduce our risk. I think we should do the same with an OpenID implementation. Sure the Infrastructure team can get OpenID to work, we just need to be sure someone also makes sure we have evaluated potential security concerns and addressed them when deemed appropriate. We may already have that person on the team - or we may need to spend the time to study some of the issues pointed out and determine if they are a valid risk and if so - how do we protect against it. ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: PHP Security Tweaks
On Sun, May 25, 2008 at 11:40 PM, Mike McGrath [EMAIL PROTECTED] wrote: Side note about this, it seems to have broken OpenID support. I've reverted to a default configuration so ricky can continue testing. If you've got a moment could you hook up with him at some point and find out exactly what configuration is causing the problem? I checked the file listing in the OpenID packages and I bet the open_basedir wasn't letting the OpenID stuff have access to the files it needed. I can modify that and allow access to those directories it most likely needs. It's a trip to the zoo day with the kids, but I will cross paths with Ricky later today/this evening and get this sorted out. Thanks! Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: PHP Security Tweaks
On Sat, May 24, 2008 at 10:18 PM, Jeffrey Tadlock [EMAIL PROTECTED] wrote: 'open_basedir' is causing issues with the user's page (i.e. clicking the jeffreyt link at the top of the page), when it is enabled it just goes to a blank page. The same happens with the Infrastructure page as well. Everything else seemed to work well with it enabled. I will play with that on a vanilla install at home and see what is up with that. I think I have this working now. I needed to add /usr/share/pear to the open_basedir list. The things I saw broken because of that last night now appear to be working. It is now enabled on publictest2. If I am not around and it turns out it is causing issues somewhere else, you can just comment it out in /etc/php.ini and bounce Apache and you'll be good to go. If something has broken and I missed it, feel free to ping me (iWolf) on IRC. If I am not around you can grab the original php.ini file from my home directory under the php-sec directory. Just copy it to /etc/php.ini and bounce apache and you will be back to the way it was before I made the changes. Please let me know if you need to do that though, so I can look at it further. Same applies. I have some garden work to do this afternoon, so if I am not around, you can copy the original php.ini from my home directory under the php-sec directory to /etc/php.ini and bounce apache to be back to the original way it was before I made changes. Just let me know if you end up needing to do that so I can look at it further. Thanks! Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
PHP Security Tweaks
I asked yesterday in the meeting about any modifications made to the default PHP install to help tighten things up a little with MediaWiki quite close to going into production. I took a look at the php.ini file on publictest2 and have a couple of suggestions to make - please feel free to comment or question any of them. I will add my own comments after each item. /etc/php.ini * Change 'allow_url_fopen' to Off. This is a big one as it can allow a remote file to be used in an include(). * Set 'expose_php' to Off. This one is just to reduce the amount of information one can gather through a script looking for vulnerable versions. Anyone determined to cause trouble could determine this information another way, like the Version info page in MediaWiki. * Set 'display_errors' to Off I think this was just set to On in testing to help with working through various bugs. But we should be sure it is set to Off for the production instance. * Set the upload_tmp_dir to a location that is only accessible by the user running MediaWiki and not readable or writeable by anyone else as well as being outside the web root. * Use disable_functions to limit what PHP functions are available. The following is a possible recommended list: disable_functions = apache_get_modules,apache_get_version,apache_getenv,apache_note, apache_setenv,disk_free_space,diskfreespace,dl, highlight_file,ini_alter,ini_restore,openlog,passthru,phpinfo, proc_nice,shell_exec,show_source,symlink,system,exec,fsockopen, dl,popen This appears to work on a MediaWiki instance I have, though that wiki is not as large or complex as the Fedora Wiki will be. Some of the items above are just information gathering components, others have a little more value to them. And then, set an open_base_dir directive in the wiki.conf file like this: php_admin_value open_basedir /var/www/wiki:/location/of/upload/tmp/dir Setting an open_basedir is not 100% foolproof to limiting access to PHP scripts, but it is another hurdle. The above config changes are some options we might want to consider. There are also tools out there like php-suhosin [1] that we might want to consider using as well to keep things as tight as possible. I have not made any changes to publictest2, but we may want to consider trying some of these config changes out and see if things still work and then possibly apply to the production instance. Thanks! Jeffrey [1] http://www.hardened-php.net/suhosin.127.html ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: user-added planet script
On Thu, May 8, 2008 at 11:57 AM, seth vidal [EMAIL PROTECTED] wrote: Should I just have the user put one (or more) planet config stanzas in a file in their homedir or have them list just the blog feed url, the hackergotchi url and their name and try to parse that out? I'm inclined to the former. So a user could just have a .planet file that has: [http://skvidal.wordpress.com/feed/] name = Seth Vidal face = http://skvidal.fedorapeople.org/skvidal.png I would lean towards using a .planet file with a config stanza similar to your example. Easy to read and easy to document on the wiki for the format. I was thinking of just having a 'ignore users' config option for the script so it would just skip their dirs if there was a problem. Having this as an option would be a good thing as well, should the need arise in the future. ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change Request: Setup Awstats for download.fp.o (and fix the torrent.fp.o one)
On Sun, May 4, 2008 at 8:44 PM, Mike McGrath [EMAIL PROTECTED] wrote: Side note about all this... I like awstats and all but I was wondering what other _OSS_ solutions people are using where they are? Just seems like awstats has... kind of been the same for years... I am another webalizer user, though I actually like the looks of awstats better - just haven't taken the time to switch analyzers. ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Hosting Linux Fest Northwest Videos on torrent
2008/5/2 Jesse Keating [EMAIL PROTECTED]: For the current need I think we're way way scaled down from fedoratv days. All I currently want to do is take the videos once converted, upload them to the/a torrent server and offer them up as torrents for a period of time. And while this might be a precidence setter, it is something of a one-off, not the start of a campaign to host all the Linux Fest videos we can get our hands on. We need to be prepared for future requests though and how to handle them. We may not be campaigning, but I am sure other groups will notice we did this for the Linux Fest Northwest and then possibly go on to ask for help with a video torrent service as well. It is probably best we work out what we say yes and what we say no to before we get too far into it. And it may be as simple as saying this *is* a one time thing until we work out those other details. In the ideal world, I do think it would be great if we could do things like this - for Fedora related videos from a conference or other talks. Brett brings up several good points on that type of service. I gave two Fedora specific talks at this event, one of which showcasing the tools and services that Fedora has created so it's not entirely non-Fedora in scope. If we to, I would be fine with just hosting the two Fedora specific talk videos. It would be great for these videos to be available. It helps people who could not be at the event hear about these tools and services and also provides material for Ambassadors and such to reference at local events they do attend - keeps us from having to fly Jesse everywhere. :) My suggestion would be (if current resources allow for it - people and hardware) that we start with hosting Fedora specific videos. Use this as a pilot program. It is easier to justify as the content is directly related to Fedora and acts as a natural filter for requests. We can use this hosting experiment as a way to better guesstimate what would need to be in place (disk space wise, etc) before offering space for other conference videos. Once we have a better idea of space, bandwidth, etc. we can determine how to scale or if we should scale to the larger offering. ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: news.fp.o
2008/2/21 Toshio Kuratomi [EMAIL PROTECTED]: This is a highly inaccurate measure of security but it's something to look at. I wonder if lkundrak and the security team have a preference for blogging/news software :-) Number of CVEs listed on http://nvd.nist.gov/nvd.cfm wordpress drupal mediawiki zope plone 2008 301710 0 2007 643772 1 2006 213941 3 I looked at WordPress a bit this morning as well. I used the same source as Toshio did, but I think I used a slightly different search than him. I used the Advanced search and set the Product to WordPress. That yielded these numbers: 2008:13 2007:42 2006:16 If you search the vuln database for just wordpress it pulls in a lot of plugins for WordPress that have issues. Even the search I did pulled in results for plugins for WordPress and not just core WordPress components. So I went through 2008 and 2007 to see which results in my search affected core WordPress bits and which were for optional plugins. Those results were: 2008: 7 2007: 36 Several of the hits for those two years had been for things like custom themes someone had provided or guest books or an image gallery. I also looked briefly at versions affected as well. Just using 2008 as an example, there were still 7 security issues listed for core WordPress components so far. But if you figure you probably shouldn't still be running a 2.0.x version or 2.1.x version of WordPress in 2008 then another 5 CVE's drop off the list leaving 2008 at 2 CVEs. To be fair, I only looked this closely at WordPress. It is quite likely Drupal's numbers would drop if I looked through those results and made decisions on which affected core bits and which affected plugins to Drupal. Like Toshio already said, this isn't the greatest way to determine the security of an app. These numbers show a big difference between mediawiki and drupal or wordpress. The questions are just how valid the numbers are and whether we're confident that the combination of SELinux (which we will then depend on; no more turning it off if we can't figure out a problem) and mod_security will keep our servers and users of the sites safe from the exploits that will appear. With any application we provide we need to consider security. I think SELinux is a valid means to help prevent damage from 0-day flaws as is mod_security. They are tools in the toolkit we can use to help reduce our attack surface. If we do move to PHP based apps, we could also consider looking at suhosin [1] as another tool for the toolbox. Thanks, Jeffrey [1] http://www.hardened-php.net/suhosin/ ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: news.fp.o
On Wed, Feb 20, 2008 at 9:53 AM, Rahul Sundaram [EMAIL PROTECTED] wrote: Jason wrote: Hi Jon, I talked to mmcgrath and iwolf this morning on irc, we found an existing ticket[1] for this idea. If the parties involved on the marketing/news sides could look it over and make sure it accurate as far as needs/goals then the infrastructure folks can see about making it happen. :) [1] https://fedorahosted.org/fedora-infrastructure/ticket/178 Yes. I filed this ticket and I have already talked to the news and marketing teams. The ticket needs updated to reflect the recent discussion that Word Press would most likely be a workable alternative to the Drupal setup being discussed towards the end of the ticket. Everyone might not be following the email thread, so having the updated, correct information in the ticket is more useful to the Infrastructure team. Thanks, ~Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: news.fp.o
On Wed, Feb 20, 2008 at 10:41 AM, Jonathan Roberts [EMAIL PROTECTED] wrote: I agree...If we could update the ticket though that would be good - I'd do this myself but don't have an account. Anybody else? Your FAS account should let you login and add a comment to the ticket [1]. Thanks! ~Jeffrey [1] http://fedoraproject.org/wiki/Infrastructure/Tickets ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Moin 2.0 (or as I call it, mediawiki)
On Feb 8, 2008 3:55 PM, Mike McGrath [EMAIL PROTECTED] wrote: There are options here, right now no tie-in exists though I'd like to have no users in the wiki at all and make everyone use FAS. This is much more feasible with mediawiki then with moin. I have not used it, but moin does appear to have an option to use LDAP on the backend. http://moinmo.in/HelpOnAuthentication/LDAP If the a move to mediawiki is not agreed on or is determined to be too disruptive to the community in general, the above may be an option. --Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: xen1 outage
2008/1/30 Dale Bewley [EMAIL PROTECTED]: Do you mean Fedora in general since this box is seen as a rarely touched appliance and you don't want to upgrade it often? Generally for this reason. Frequent upgrades are rough in an environment that is supposed to be up most of the time. Especially when that box houses several VMs. --Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Infrastructure IRC Meeting Logs Updated
Just a heads up that I added IRC meeting logs to the Wiki from 1/11/2007 to 2/22/2007. They are located here: http://fedoraproject.org/wiki/Infrastructure/Meetings --Jeffrey ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
