Re: [Openstack] [OpenStack][QA] Writing a test plan for blueprint: Use common RPC listener to consume messages
Nir Magnezi wrote: My name is Nir, I'm part of rhos-qe (Redhat Openstack QE team). We are testing openstack and currently writing test-plans for the new Havana features. This discussion probably belongs to the openstack-dev mailing-list, which is focused on discussing development of the next OpenStack release, whereas this list is mostly focused on the current state of affairs. See https://wiki.openstack.org/wiki/Mailing_Lists for details. -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] IMPORTANT: Openstack List Migration (Please read)
Sylvain Bauza wrote: Hi Paul, Apologies if I missed any related info, but how to subscribe to the new lists.openstack.org list ? I can't find my way thru mailman [1] My understanding is that the current subscriptions will be migrated to the new list automatically. I suspect that direct subscription will not be available until the migration occurred. -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Havana-2 development milestone available
Hi everyone, The second milestone of the Havana development cycle, havana-2 is now available for Keystone, Glance, Nova, Horizon, Neutron, Cinder, Ceilometer, and Heat. In the last 7 weeks, more than 100 features were added and more than 650 bugs fixed. You can see the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/havana/havana-2 https://launchpad.net/glance/havana/havana-2 https://launchpad.net/nova/havana/havana-2 https://launchpad.net/horizon/havana/havana-2 https://launchpad.net/neutron/havana/havana-2 https://launchpad.net/cinder/havana/havana-2 https://launchpad.net/ceilometer/havana/havana-2 https://launchpad.net/heat/havana/havana-2 The next (and last) development milestone of the Havana cycle, havana-3, is scheduled for September 6th (final release is planned October 17th). Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (July 16)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The TripleO effort was accepted as a Program, with the following mission statement: Develop and maintain tooling and infrastructure able to deploy OpenStack in production, using OpenStack itself wherever possible. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-07-16-20.02.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Horizon] [UX] phabriactor/pholio as a possible UX option
Monty Taylor wrote: Sorry - we've been a bit busy and this got put on the back burner. I believe that ttx has done some work over the last couple of weeks ... Theirry, any updates from your end? What I've been working on addresses task tracking, not really the needs of UX discussions. My suggestion was to use Discourse because I can see where our current setup (pure task tracking + pure MLs) is missing the needs of image-intensive multi-threaded discussions, and that sounds more reusable than GitHub issues which bleeds into task tracking a bit. Cheers, -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (July 2)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * In order to simplify its taxonomy and recognize more types of contributions, the TC defined official 'Programs' by adopting the following motion: 'OpenStack Programs' are efforts which are essential to the completion of our mission. Programs can create any code repository and produce any deliverable they deem necessary to achieve their goals. Programs are placed under the oversight of the Technical Committee, and contributing to one of their code repositories grants you ATC status. Current efforts or teams which want to be recognized as an 'OpenStack Program' should place a request to the Technical Committee, including a clear mission statement describing how they help the OpenStack general mission and how that effort is essential to the completion of our mission. If programs have a goal that includes the production of an 'Integrated' deliverable, that specific deliverable would still need to go through an Incubation period. The initial Programs are 'Nova', 'Swift', 'Cinder', 'Neutron', 'Horizon', 'Glance', 'Keystone', 'Heat', 'Ceilometer', 'Documentation', 'Infrastructure', 'QA', 'Oslo', 'Trove' and 'Ironic'. Those programs should retroactively submit a mission statement and initial lead designation, if they don't have one already. The TC asks that the chair modifies the charter accordingly, including replacing the word Projects by Programs where appropriate. Our project documentation on the wiki will be updated accordingly. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-07-02-20.01.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Horizon] [UX] phabriactor/pholio as a possible UX option
Monty Taylor wrote: However, I still don't feel like I fully understand what the requirements list are here. github isn't a requirement, it's a suggested solution, and one with already distressing massive negative implications. so I'd like us to work on what requirements the tool needs to have so that we can figure out solutions that will solve them. So far, my understanding is that requirements are: - discussion - messages containing images - possibly specific image annotation/commenting As a data point, Discourse could also be a solution: http://www.discourse.org/ It's clearly a discussion tool (including pretty advanced threading, post likes, etc.), and messages can contain images. See a design discussion for example at: http://test.ubuntu-discourse.org/t/a-ubuntu-ish-theme-for-the-site/177 -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-017] Issues in Keystone middleware memcache signing/encryption feature (CVE-2013-2166, CVE-2013-2167)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-017 CVE: CVE-2013-2166, CVE-2013-2167 Date: June 19, 2013 Title: Issues in Keystone middleware memcache signing/encryption feature Reporter: Paul McMillan (Nebula) Products: python-keystoneclient Affects: version 0.2.3 to 0.2.5 Description: Paul McMillan from Nebula reported multiple issues in the implementation of memcache signing/encryption feature in Keystone client middleware. An attacker with direct write access to the memcache backend (or in a man-in-the-middle position) could insert malicious data and potentially bypass the encryption (CVE-2013-2166) or signing (CVE-2013-2167) security strategy that was specified. Only setups that make use of memcache caching in the Keystone middleware (specify memcache_servers) and using ENCRYPT or MAC as their memcache_security_strategy are affected. python-keystoneclient fix (will be included in upcoming 0.2.6 release): https://review.openstack.org/#/c/33661 References: https://bugs.launchpad.net/python-keystoneclient/+bug/1175367 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2166 https://bugs.launchpad.net/python-keystoneclient/+bug/1175368 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2167 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRwdC5AAoJEFB6+JAlsQQjOTQP/1q8R6aPU9RcbsZ5pRm4YU7L gp1XHpoCKmAAFhPjVbjOXLfW0xAfa0B+ATG/BeM4dvysgnQIRb21D4vu4wqCyLq/ Mw6pvytEyd5hGWpSY5eG6cQJ+UrACRDRgjMDIrR6PkwfWK0wW1p+2XzbzH9WIO7F u4/oneUOSlN04wLd1qx0hy2mybFGUu8rPsJyaPJq2qivhGOwIOq85WddurtK1wXl aTdYnavJxmUsTLFHjlpveKaEmlGrYNxeAMTpkZiSANPxU9rcjZNNEmgdGriV1Cdp U3A08z+s7UiZT10cXg3y3C3pNV+upiS5b939fvrSCdJcMmSUBDZ9Bz9zpMYZ/EZm gJLBe2HskHmOfUzdgmVla2HLKqex/no4aLqbVBLkpFhkesKWz+2mTjvTAygjL5vg Ps8viGv80b1DwSUoyI22VChDkXmarkfOFbIdl7yu3h6LDXOSUawA1OiELjlSHyB4 AM1Vl3bSYT9MSHvwymSd4ML/nH01nE0COb1kLzWEqDyFUfq6NjyCOkb74rgrjLH5 E1LVG/4DyYtQ0unOtIT2wyYqEUINAV/qv/GwkhMqroGbPle63+OLRaDtVSciiEdj z/ljz6eMGEeD/cHi80yhsKGo0HjmXzG3X83Y6cSaqWbXUvIw0kbidLwX4fzlnGr0 JCWckqbCAwwKyRNAADVb =1zJ2 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-015] Authentication bypass when using LDAP backend (CVE-2013-2157)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-015 CVE: CVE-2013-2157 Date: June 13, 2013 Title: Authentication bypass when using LDAP backend Reporter: Jose Castro Leon (CERN) Products: Keystone Affects: Folsom, Grizzly Description: Jose Castro Leon from CERN reported a vulnerability in the way the Keystone LDAP backend authenticates users. When provided with an empty password, the backend would perform an anonymous LDAP bind that would result in successfully authenticating the user. An attacker could therefore easily impersonate and get valid tokens for any user. Only Keystone setups using LDAP authentication backend are affected. Havana (development branch) fix: https://review.openstack.org/#/c/32896/ Grizzly fix: https://review.openstack.org/#/c/32895/ Folsom fix: https://review.openstack.org/#/c/32894/ References: https://bugs.launchpad.net/keystone/+bug/1187305 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2157 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRue20AAoJEFB6+JAlsQQjiHQP/1Jd8p9Zezo70Vdm4oZksDzH IPuFfeCRUhLvDC1ygz33/7CbRkFtmJS8C+PG+WxiG/49bsCBfIN5fHlOf3DY2X1U 9zgodo3Tm/LwKCrpdceu4VCABt7CtO/CsHnuQGWBOf06MLDTqDvz3LQKpcPXO50l 1OHiOWEX9nbCkNKRCPfK4QfrzbJM5GufEeoEEfKk8ZctivvI2M56OcSiGMdOhGK8 Xw+0bGzBBZzBMhiMq2iw7y0JqWtRLTND/AAP1eyjbHL/xDG/rTtECGaGuONXjpSk WQRpWMznJY83fBnxnVAvKvf6OxG8IW8YNicvTgfx5v9gvX0U00r59y24ClnmvBxb oRWES8bRLHmjf8vTtfZwcATEfUUFZZK+9VUsaIRsRF6+gF/fbQq39SdVESQACvks Sf9/f/Tu6u+58Je2JaTmx3LLV6u12ellP/GUr31OyihKAxFGK4Y1tdrO3v4+u2ZF lSC361D5r5cczTosmXy5HjXwfjATaGuMb1ycDKCmO+98gsluQ1exDFnIXCw38weN KWJIp5zVCdTF0rqZCr3xDBSe4aukX8niBJNnvgJwELAddIWZ6FHUuEsgl3UPs7ZD E+issrQHaGtOJpNvoj17uxxnTY2VrtJ2AjxiU7y+hmt9tHh78rx+OhAdn7zPdoeT EEJ4OWpjLDKre9HsJVxX =kubz -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack CVE Wiki page
Jolyon Brown wrote: In my (day) job (not Limilo!) we're currently evaluating an IBM product which is underpinned by OpenStack. During review our InfoSec people claimed many (22) open CVE vulnerabilities for the underlying version of OpenStack used (Folsom). I don't believe this to be the case, as Launchpad lists only 3 CVE bugs. However it's not clear at a glance if these 3 have been back ported, which versions are affected etc. While I know my way around enough to find out, new people investigating OpenStack might not, so I was looking for a summary page of open vulnerabilities broken down per release. Now I know the community does a great job regarding security related bugs, both finding and fixing, and Thierry in particular is working wonders regarding CVE notification. A quick google for OpenStack CVE though brings up https://wiki.openstack.org/wiki/SecurityAdvisories in the first few results which looks as though it may have been the intended place for this kind of summary info, but it looks a bit neglected. Given that this may be the first query someone tries when evaluating OpenStack I think it might need a bit of an update. Is there somewhere else that contains this kind of info in an easily summarised up to date format? Or should the wiki page mentioned be the one to be updated? Hi! The official source are the published (and signed) OpenStack Security Advisories (OSSA), but I agree it can take a bit of effort to get historical information about them, and we need to improve on that. We published OSSAs to this list from the beginning, and starting in July 2012 we also published them to openstack-announce for easier access. There is a community-maintained wiki page[1] listing them, but I would like to transition that to a more official (and less prone to editing) area on the main openstack.org website. We also started recently to create ossa tasks on Launchpad, and I retroactively created them for all 2013 advisories. Together with Launchpad CVE linking features, that gives you a nice list you can access at [2] -- maybe it would make sense to retroactively create ossa links for all advisories ever published. Matt Joyce also started working on an OpenStack Common Vulnerability Database [3] which may help in accessing more structured data. So in summary... yes this is currently harder than it should be and I'd like to fix that. Yes you're welcome to edit [1] so that it's made more current. If you think it has value I can retroactively mention past OSSAs in [2]. And you should have a look at [3] :) [1] https://wiki.openstack.org/wiki/SecurityAdvisories [2] https://bugs.launchpad.net/ossa/+cve [3] http://secstack.org/2013/04/openstack-common-vulnerability-database/ Hope this helps, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack I release naming
The poll closed a few minutes ago, the results are in: 1. Icehouse: 102 2. Ichang:73 3. Inverness: 58 The *next* release cycle for OpenStack, starting in November 2013 after we conclude the current release cycle (Havana) will therefore be called Icehouse ! https://launchpad.net/~openstack/+poll/i-release-naming Thanks to all participants to the poll. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OSSA 2013-013] Keystone client local information disclosure (CVE-2013-2013)
Robert Collins wrote: What if we were to always do a release after a security advisory? We don't do a server stable release after each security advisory as it doesn't significantly help spreading the fix, but I agree that for client libraries (where the PyPI releases are the main form of downstream consumption of the fix) it makes sense to tag and trigger a new PyPI release after each security advisory. These were the first advisories on client libraries, but with Keystone middleware being shipped within python-keystoneclient, I expect more in the future. -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Havana-1 development milestone available
Hi everyone, The first milestone of the Havana development cycle, havana-1 is now available for Keystone, Glance, Nova, Horizon, Networking, Cinder, Ceilometer, and Heat. It contains all the new features that have been added since the Grizzly pre-release Feature Freeze in March. You can see the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/havana/havana-1 https://launchpad.net/glance/havana/havana-1 https://launchpad.net/nova/havana/havana-1 https://launchpad.net/horizon/havana/havana-1 https://launchpad.net/quantum/havana/havana-1 https://launchpad.net/cinder/havana/havana-1 https://launchpad.net/ceilometer/havana/havana-1 https://launchpad.net/heat/havana/havana-1 Including the oslo libraries, 63 blueprints were implemented and 671 bugs were fixed during this milestone. The next development milestone, havana-2, is scheduled for July 18th. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-014] Missing expiration check in Keystone PKI tokens validation (CVE-2013-2104)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-014 CVE: CVE-2013-2104 Date: May 28, 2013 Title: Missing expiration check in Keystone PKI tokens validation Reporter: Eoghan Glynn (Red Hat), Alex Meade (Rackspace) Products/Affects: Keystone (Folsom only), python-keystoneclient (0.2.0+) Description: Eoghan Glynn from Red Hat and Alex Meade from Rackspace both reported a vulnerability in expiry checks for PKI tokens in the Keystone authentication middleware. Expired tokens for authenticated users could continue to be used, potentially resulting in the bypass of intended security policies. The effect of PKI token revocation is also reversed when the token expires, in the sense that a revoked token is once again treated as being valid. Only setups using PKI tokens are affected. Note: The affected code was added to Keystone in the Folsom release, but was moved to python-keystoneclient during the Grizzly development cycle. python-keystoneclient fix (will be included in upcoming 0.2.4 release): https://review.openstack.org/#/c/30742/ Keystone (Folsom) fix: https://review.openstack.org/#/c/30743/ References: https://bugs.launchpad.net/python-keystoneclient/+bug/1179615 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2104 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRpRVGAAoJEFB6+JAlsQQjBRAP/iyScNAht67EMgGed4GWNKd3 2zHOgmqIq31S558ugul1e3qNgggnQ0qJvI1RjcgZuKoJEhH8SaPZBuykyycSvO9M L2Bex+GKAGAMuaz4ryPcnt7xJg+Mc0cksdCldeW1pXMrt8yITSQgXe0GqnGssoC+ 5TCk7JG8ADczbDGMa/nyc65tksbEI8hNJYyLLbCapvxfz4VqL2r5yp0vT0/jWDxy FLocAYnoKm9oxl0In5zioMQs0cSYAAa5EjwMLMMmUF/Axa7GskUOME8Q/GdgpMzJ h5AutinbpANSysz8pTB9bps7WSq33KfGKBN23caP43XvyMVA6CTsLUJH+U/9n+9u 0rTmKcumLXW9nkf5leki1u69VqRZFksrcEzJVtXdDyGGvFbZjPLcoA8lWifluSK/ vhu+T+RSnFWicki/Ifiz7c4tK6RYSB+a4G3/982GBxKp1sm3WLKd3ljsmpsqFeAY sz1o6p8zTgKIsYKrFEO6wMx37Qiga1RRB0As9msmAHJ6LXTO5ev8LcxXBjRjSIPs kTxoxHomRhbJAigvw+qSNSZz3DjrEywcqlNLLINQio21gzPMP4v1GVzwvroI8akf 6oz4DLDMcbdI1yQ7jjEhpnrcpFRHrJi2a45Tv6dlto34LvG7gLvgmLgnkJs0XMw7 BslUz5cGAucwXTz2vSHs =bu2N -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Splitting the Identity Backend
Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. [...] I think it makes sense. The main blueprint for this is: https://blueprints.launchpad.net/keystone/+spec/split-identity with supporting blueprints for pieces that can be completed interdependently. If this is a project you intend to complete in the Havana cycle, it would be nice to propose the series goal to Havana and set target milestones for when you think that work would land. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] security blueprint related to os binaries
Kevin L. Mitchell wrote: On Tue, 2013-05-14 at 18:38 +0300, Vasiliy Khomenko wrote: Attacker can put binary in /usr/local/bin for example. on ubuntu that path located before /usr/bin. If the attacker has write access to /usr/local/bin, it's already game over; I don't see what we can do to nova that can mitigate something that disastrous. Yes, this proposal is pretty useless. We rely on $PATH to execute code as the $service user -- someone that can modify $PATH or inject binaries in it already has enough rights to act as $service. For rootwrap calls we rely on a root-configured specific path, and still have the option to specify the complete path. To interfere with that you actually need to be root already. So this makes the code more brittle (each distro would have to patch the code to apply their specific paths), for no security gain. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Anne Gentle wrote: I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I promise, it wasn't the world's most fun session. :) I'm sure. :) I think I don't have much regret but do feel sorry that I don't know more. The Etherpad is here: https://etherpad.openstack.org/ProjectsReNaming I think there is much more value to codenames than just avoiding the cost of a rename when the project becomes OpenStack. This was captured in the session: Codenames drawbacks and benefits (-) Lack of trademark protection (-) Confusing to newcomers (-) Shadow their more official counterparts (+) Short names are highly-convenient and efficient, often less ambiguous (in conversations, executables, modules...) (+) Help building project and team identity (+) Separate the project itself from its functional scope (so they remain valid even if that scope evolves) Those last two bits are pretty essential. There is a reason why a functional description cannot be used as a project name. The project (as in, the code repository and the community of contributors around it) is *distinct* from the functional scope of what its code does. Take Ceilometer (OpenStack Metering). What happens when they grow to cover Monitoring ? You rename the project to OpenStack Metering and Monitoring ? Or you keep the partial functional description ? I'd rather avoid to rename everything every time a project evolves. Those renames are *extremely* costly, as we'll soon enough realize. I find the confusing argument pretty weak myself. Brands are used everywhere, so we are used to make the translation between a name and a function. Microsoft named its desktop environment Windows, rather than Operating system or Desktop environment, and it took people about 5 minutes to get used to it. Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and your repo kumquat. If you call the CLI os-metering, you'll have to rename it when the scope expands, or live with a name that looks like a functional description but is not an accurate one. I very much prefer to call it ceilometer. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New code name for networks
Monty Taylor wrote: So, with all due respect to the many awesome lawyers who are involved with the project, what I'm getting at is that we need to do the right thing as best we can based on unofficial advice from well meaning people who may or may not have legal backgrounds as well as input and help from Jonathan Bryce and the foundation board where appropriate. FWIW Mark McLoughlin tried to organize a bit that unofficial advice and set up a legal-discuss mailing-list where this unofficial advice can be easily and publicly discussed. http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OSSA 2013-011] Keystone tokens not immediately invalidated when user is deleted (CVE-2013-2059)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Looks like a fix has been written for Grizzly. Is there an official Grizzly patch release coming out that contains this and other fixes? Point releases for the last OpenStack release, containing all security fixes and high-impact bugfixes, are regularly produced. It happens that 2013.1.1, the first Grizzly point release, shall be released today. - -- Thierry Carrez (ttx) Release Manager, OpenStack -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRjKnqAAoJEFB6+JAlsQQjjz0P/071kbwjUGER0XK+bdNPEeJP gbgr9NRcw/pxXCNykcR9MmMk7iBARYWVcBK8hDWatffAKnSf5XNyAZlRfl//KCiA vXnlHq1WhaXbiAtpCPqiex9WBX0jdcbYNHrEQ8oiwB3zO/abqaTowhG4rH8xWEEz sW4uoiLadEB+/fKNbH80PEh8AdxWi2wtXrpG4ik1pS+c3eTrotWLdqzFEhN7YV+k cyTEL3t/IZeBQ7GwFWgNSbiM0HS+LB86M36h7rrer1VPe0ndG5pk1Mcq2CgjRJ4f wkgQZrfbBGda9hJq3BjCg+BMgz6AlB5XycNJhn7UwVWu2s+KdgbY707owKYuyRxB wUd8GVXdrpp8a1KrY/KqB9dNZMse/DKhWA1qy4b9SiOpYdJ4PuIj/ekP7nk7r9K2 DytmI7kvZVlqHs9ubb3QvkF+zXb9yifYVIZgNjCzS2iaqVamxEIBpWonpWVsUR52 I8hj76lbGDK4ZLk+QekfmXau4LOFdZjzfJzmP7mJx8QETSnwE4m7GkwJfWC3JO80 M4zQ9ZZzEwwFNWmiITaQEZILTp2jECdRDSb58sn4mTP/nsfCh46VbguwT4Qc2ZB2 aF/ceVAamz7k9wzz3Vnwig1YSF0CcYFlSNJyiYh54fm492c77qWpVsUCQSZuFo+x D2WZ06+5mVLlyMELkfo/ =3aK8 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-010] Nova uses insecure keystone middleware tmpdir by default (CVE-2013-2030)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-010 CVE: CVE-2013-2030 Date: May 9, 2013 Title: Nova uses insecure keystone middleware tmpdir by default Reporter: Grant Murphy (Red Hat), Anton Lundin Products: Nova Affects: Folsom, Grizzly Description: Grant Murphy from Red Hat and Anton Lundin both independently reported a vulnerability in Nova's default location for the Keystone middleware signing directory (signing_dir). By previously setting up a malicious directory structure, an attacker with local shell access on the Nova node could potentially issue forged tokens that would be accepted by the middleware. Only setups that use the default value for signing_dir are affected. Note that future versions of the Keystone middleware will issue a warning if an insecure signing directory is used. Havana (development branch) fix: https://review.openstack.org/#/c/28568/ Grizzly fix: https://review.openstack.org/#/c/28569/ Folsom fix: https://review.openstack.org/#/c/28570/ References: https://bugs.launchpad.net/nova/+bug/1174608 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2030 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRi72dAAoJEFB6+JAlsQQjJZAQAJ5w/+BoBD4em8YklBsxU6wU Bn1wWu3W5ngCNuHwr4ydWzC3U1TT1zWtogWJpv/+87m2KPESWhs7YGCkTIE9tLpA sNOniOG9hGUsWwRgtUqjA8/8QzLgbNJ/PDJx0lrNPNkvMbHwP/jxotx353edhelQ QAPJwVPBqu0vn2VZOeFWYNO/AnWNcjTXE0po92qaFvw3HWL3ykMd30w4Ejxv9clC VjBjaNkReSkmcd/BaArtr1IenyYyVqM7nv/VWl5O5Up02+uvAozDmy6Cyc1O5VOW 6m9nRH2WKE/bFXcTEG4rpH+/BZxG2RuyklUBvVtSaEAQOWYFSwQKzjxGM3rItsWt iuQYrakl6H69tRS3HS9pAXWdxSikSb8CqmVJauf3RG1/EQ7GtCO0kXVPi8fYBaTX GpLmpY8bj6o2iY1Kh1bozZ2oYVLgPrhP2R4oj+4iaSN++gy2qs0d3AvIK0BzBKT+ fd7wAUpdxltM9eZS82VEQxIaOGUDqnGompEu3nPRv9KD5kZqgz/L/jp5I+PR3y1D Uaj8W+FfF/AZtMRLJHl3I0kUHRhfuIusir5zja7UCoR6UEeipLvBzbi/DSGfBCRY /VbBv9ZZBeQ+Kw4EwS4/7G5nw1RX4/bKGSi0zcwwmD2unB7Plm9MjI65yR4oFidl uOpCYFwNk6PqCFED/mCz =wjZ/ -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-011] Keystone tokens not immediately invalidated when user is deleted (CVE-2013-2059)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-011 CVE: CVE-2013-2059 Date: May 9, 2013 Title: Keystone tokens not immediately invalidated when user is deleted Reporter: Sam Stoelinga Products: Keystone Affects: All versions Description: Sam Stoelinga reported a vulnerability in Keystone. When users are deleted through Keystone v2 API, existing tokens for those users are not immediately invalidated and remain valid for the duration of the token's life (by default, up to 24 hours). This may result in users retaining access when the administrator of the system thought them disabled. You can workaround this issue by disabling a user before deleting it: in that case the tokens belonging to the disabled user are immediately invalidated. Keystone setups using the v3 API call to delete users are unaffected. Havana (development branch) fix: https://review.openstack.org/#/c/28677/ Grizzly fix: https://review.openstack.org/#/c/28678/ Folsom fix: https://review.openstack.org/#/c/28679/ References: https://bugs.launchpad.net/keystone/+bug/1166670 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2059 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRi8UUAAoJEFB6+JAlsQQjarMQAL64x2OlW3SbgOoCUDhi91lv JdBStMO6/6H1Njjv0cLEAOE/50rAJSFLsdLlzSkXHimD9NWnXogpbaKj+gWd/Jbm xDOgVtRDa8IgmaXVgA88tAO0/C6QHTQMBwBce8hVzMRRDZZ6zW7SAvofTBjdjmEj tC8nwhxF/QAx/lHwIyWHQsGCip+z9JQxT+UCQ5ytQQbSnYI/wmRWMHCCcst7XFqn H6Y9LQ8cLQAOZk0fHZx7wsFFVJ9XIiQcZxYSGPDn5/aRXlbbF6cWTy4UPB3jmMkp wJ7XSjpXzPLsTCimXwYT9CkhUYjvC7Y9Yu2XF3VycFL+bifobIfPQ2ABNBqkd/U1 2iIMq8rCTIG+GEhgBMHyrBdXJclsdzY/mFOHZhOdCsLH2pO6EPCUjO3Zs6BPtYfk zBNPRzrUXAnay+xjJhjQqxCOuskx/gxt2kOF00G1c/jZTytqzx7M4yf5GL9DYD6g LLUZpb+Ia5voocBpK2484fXlouVoQY+encQopnSZb5GarsMgO1hRK8qtExeeR3+o NPxeat15YaSvVaCgSL2msqnjIr6g3wXI1vLGdvmGny4hvNnLd+UeeQ9eT0Nc7LN9 aotaXRhDeYz71aFd8ZCYpUtoZ6I50/XnRT9+FrQ2QZ7cEKSVZjUv+mcEn0mCvZpC hqKVwOK6strcPXDlQwZr =e4jK -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (May 7)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The TC approved the Reddwarf project for incubation in the Havana cycle * The TC approved the long-term removal of baremetal-specific code from Nova's scope, and accepted the new Ironic project (which will contain the split of this baremetal-specific code) in incubation in the Havana cycle See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-05-07-20.01.html More details on the new project inclusion process at: https://wiki.openstack.org/wiki/Governance/NewProjects More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] I release naming (calling APAC community)
Jacob Godin wrote: +1 Ili Thanks for all the suggestions ! We probably have enough place names so that we don't need to extend the naming rules to things that are not place names. So far, the only suggestion that fits in our strict naming rules is Ili (a city or county in the country/state where the design summit is held, single word of 10 characters or less). To have more than one option, we'll probably extend the rules to include other places (like street names) in Hong Kong itself. We'll go through name checks and set up a vote soon, I'll keep you posted. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Gabriel Hurley wrote: I'll throw it out there again: We really ought to deploy an OpenComparison site (http://opencomparison.org/) for OpenStack. It's awesome, and does massive amounts of goodness for managed information and discovery. Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? I'd hate it if related projects had to register to multiple sites to get properly discovered. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] I release naming (calling APAC community)
Hi everyone, As you may know, we name our release cycles after cities or counties in the state/country where the corresponding design summit is held. That creates an interesting problem for the I release, since there is no word starting with i in classic transliteration of Chinese words... so not so many candidates. We'll have to get a bit creative and be willing to bend the rules a little. Feel free to suggest names on this thread, or on the wiki page at: https://wiki.openstack.org/wiki/Release_Naming I am especially interested by the input of our APAC community in general and our Chinese members in particular, which are probably the best to let us know which transliteration crime could be acceptable or which name they would particularly like. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] release process and sample configs
Darren Birkett wrote: I've noticed that a lot of the projects do not get their sample configs updated as part of the release process. I'd suggest that one of the final commits to each project before a release is cut, is to update the sample config so it's relevant to the codebase that's being released and packaged. For those that aren't aware, in each project there is a script that can be run that will parse the entire project tree and extract all options cleanly into a new sample config file, so it need not be an onerous task That's a very good point. This should be done before the first release candidate is cut -- and tested/refreshed if necessary afterwards. I'll add it to the release process. I also think that the entire sample config should go into the docs for a release, so that people (non devs) don't need to hunt around in the source code to find the elusive option they want to use. I'll let Anne comment on that, but it sounds sane to me :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Heat PTL nominations are open
Hi everyone, As you may know, Steve Dake resigned[1] from his Heat PTL position for personal reasons. Now that the summit is over, we should start the selection process for his replacement. If you would like to announce that you would like to be the PTL for Heat for the rest of the Havana development cycle, please send an email to *openstack@lists.launchpad.net* with subject Heat PTL candidacy and a description of your platform. This self-nomination period will end on Monday, April 29, 23:59 PST. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-April/007396.html -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Patch not applied to grizzly?
Dennis Jacobfeuerborn wrote: I just deployed my first openstack controller using the puppet modules from stackforge and the grizzly packages from RDO and it seems there is a problem that apparently has been fixed but that fix didn't make it into grizzly. Since this is a controller node there is no cinder-volumes service running yet. As a result when I try to create a volume openstack tries to create a volume which then gets stuck in the creating stage and cannot be deleted. The issue is described here: https://bugs.launchpad.net/nova/+bug/1053931 While the bug has been marked as fixed I still see this with my grizzly setup. That would be a regression, since the patch for that bug landed in Cinder and is apparently still there. Could you file a new bug, referencing the original bug, at: https://bugs.launchpad.net/cinder/+filebug Thanks in advance, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] ODS schedule app for Android?
Eric Windisch wrote: Someone has just informed me of the @OpenStack twitter feed which reads: Coming to the Summit? Download the new iphone app! (Android coming soon) awe.sm/dE87S http://awe.sm/dE87S Case closed, I guess ;-) A Google Play search yields: https://play.google.com/store/apps/details?id=org.sched.openstacksummitapril2013 -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] root_helper deprecated?
Rahul Upadhyaya wrote: I think you should use : rootwrap_config=/etc/quantum/rootwrap.conf Found this at below mentioned wiki page. I think this should hold true for Quantum too. No, Quantum still uses root_helper and has not transitioned to using rootwrap_config yet. Looking at the code, the message seems to point to configuration sections. The [DEFAULT] root_helper configuration option is now deprecated, it needs to be specified in the [AGENT] section of quantum.conf. See https://github.com/openstack/quantum/blob/master/etc/quantum.conf for an example. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] what would be the best wat to get security notifications for openstack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matthew Thode wrote: I've been packaging openstack in Gentoo but have been relying on others to watch you guys for security bugs. What would be the best way for me to get notification when a security bug is fixed (when a security patch is accepted), so that I may update the packages. Cross-posting is evil! Answers went to the openstack-security list. Cheers, - -- Thierry Carrez (ttx) Release Manager, OpenStack -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRZDTWAAoJEFB6+JAlsQQj4xAQAIGursAKMIgv7EsoZR508uWq O0n5LPW56YByOuuc1DbpnNt1gOSJHWWlBrQEILYvYsVTiQF5UeVwXl66I6ohJaFG LQrWRSx+TJXmlMzgt0JgVF7/TlG0Z5BBQXOPv/t3Y4wgmsJTwlEcHthNDP5IMYzR OZ6AXjFakTJn5UIir3MlehJm6dAyVIxJTqkHN458nDoOGF9JhXFerrsP9uQtnrHX ug3xh1lkjmFqEX50PS2xS8jvb3LuOF6H+H6f+9WQV3+WMpqfkTVOo3uhNG6q5Qpe vtNx2x2QkuTyNMxu7gXxYev/KNLiGVyOcDJ38PTX/0khgMJ+D6ncv++/4U82tNqU zvo/go9m6UaR1sI2rL55Ly2AXHzPcuG09HZ+/Wpzw2HgrmkRHSknJUZfm8Sh9wZf prYum8Ivty1ejuhbSX1e4UDS6bq9dVdBAGiMMtOsK/qrfbOewOQgedog+kJ0QPmG NYhgWbc+1Dqyq/xuGuI8KeqzjJ7qFGcqHzsev2bgl+RAcJqY5++KU/RHlbG7PtFF 1GMC/UJLEkFCR0wOIWTrhvRSZ31IPlok9SVRnAyXwk15NrLy2mwXVj1qQFtkamTh nNt5jz0MWopj2s3bZUkO3vldzsphmb0i3Hvdm6GssbVbSdC2iX0rCwcn9vd5uwVZ ogUB7IzoWf6yQTg0cqjr =qpJ5 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Cinder] Blueprint to be added for Cinder in G version
Sheng Bo Hou wrote: Hi folks from Cinder and OpenStack community, I have viewed the page https://launchpad.net/cinder/grizzly/2013.1. Shouldn't we add the blueprint ISCSI chap support (https://blueprints.launchpad.net/cinder/+spec/iscsi-chap) into it, since it is implemented? Nice catch. Added to the list. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack 2013.1 (Grizzly) is released !
Hello everyone, The Grizzly development cycle, started 6 months ago, ends today with the immediate release of OpenStack 2013.1. It is the result of the work of 550 different people who contributed code, documentation, or infrastructure configurations. This amazing journey saw the implementation of 232 blueprints and the fixing of 1900 bugs within the 7 integrated projects alone. You can find source tarballs for each integrated project, together with lists of features and bugfixes, at: OpenStack Compute:https://launchpad.net/nova/grizzly/2013.1 OpenStack Object Storage: https://launchpad.net/swift/grizzly/1.8.0 OpenStack Image Service: https://launchpad.net/glance/grizzly/2013.1 OpenStack Networking: https://launchpad.net/quantum/grizzly/2013.1 OpenStack Block Storage: https://launchpad.net/cinder/grizzly/2013.1 OpenStack Identity: https://launchpad.net/keystone/grizzly/2013.1 OpenStack Dashboard: https://launchpad.net/horizon/grizzly/2013.1 The Grizzly Release Notes contain an overview of the key features, as well as upgrade notes and current lists of known issues. You can access them at: https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly In 11 days our community will gather in Portland, OR for the OpenStack Summit: 4 days of conference to discuss the state of OpenStack and a Design Summit to plan the next 6-month development cycle, codenamed Havana. See https://www.openstack.org/summit/portland-2013/ for more details. Congratulations everyone on this awesome release ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] CY13-Q1 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack
Qingye Jiang (John) wrote: I saw Jay's suggestion on removing review.openstack.org from the git domain analysis. Can you shed some light on how this system works? Is this system shadowing more real code contributors? Merge commits are created in git history when branches are merged. They appear as having two parent commits. In OpenStack, our Gerrit review system automatically creates them when merging into master, so jenk...@review.openstack.org appears as the author of all of them. Other projects include those as well (see https://github.com/apache/incubator-cloudstack/commit/987604216728aa42756c55290495ad55b7449cf3 or https://github.com/eucalyptus/eucalyptus/commit/df0432f2c5319b1e41122755b701ddab9b802852), but they appear under the name of the person who manually pushed them. So I would just go with Jay's suggestion and exclude the review.openstack.org domain from the domain analysis. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone Grizzly RC3 available
Hello everyone, Due to recently-reported performance issues, we created a new Grizzly release candidate for OpenStack Identity (Keystone). You can find the RC3 tarball and the list of fixed bugs at: https://launchpad.net/keystone/grizzly/grizzly-rc3 This should be the last Grizzly release candidate for Keystone. Unless new release-critical regressions are found that warrant another release candidate respin, this RC3 will be formally included in the common OpenStack 2013.1 final release Thursday. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/keystone/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it at https://bugs.launchpad.net/keystone/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Only a few days left to make Grizzly an awesome release ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Quantum] OpenStack Networking Grizzly RC3 available
Hello everyone, Due to a routing issue in the load-balancing feature and another with Unicode characters in the XML support, we created a new Grizzly release candidate for OpenStack Networking (codenamed Quantum). You can find the RC3 tarball and the (short) list of fixed bugs at: https://launchpad.net/quantum/grizzly/grizzly-rc3 This should be the last Grizzly release candidate for Quantum. Unless new release-critical regressions are found that warrant another release candidate respin, this RC3 will be formally included in the common OpenStack 2013.1 final release Thursday. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/quantum/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it at https://bugs.launchpad.net/quantum/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Two days left ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nova and Glance Grizzly RC2 available !
Hello everyone, Here is the last round of this week's respins. Due to various reported bugs (including an issue upgrading from Nova Folsom to Grizzly), we created new Grizzly release candidates for OpenStack Compute (Nova) and OpenStack Image Service (Glance). You can find those RC2 tarballs and see lists of fixed bugs at: https://launchpad.net/nova/grizzly/grizzly-rc2 https://launchpad.net/glance/grizzly/grizzly-rc2 These are hopefully the last Grizzly release candidates for Nova and Glance. Unless new release-critical regressions are found that warrant a last-minute release candidate respin, those RC2s will be formally included in the common OpenStack 2013.1 final release next week. You are therefore strongly encouraged to test and validate those tarballs. Alternatively, you can grab the code at: https://github.com/openstack/nova/tree/milestone-proposed https://github.com/openstack/glance/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it on Launchpad and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Release day is Thursday ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Horizon and Swift Grizzly RC2 available !
Hello everyone, Due to various reported issues, we created new Grizzly release candidates for OpenStack Object Storage (Swift) and OpenStack Dashboard (Horizon). You can find those RC2 tarballs and see lists of fixed bugs at: https://launchpad.net/swift/grizzly/1.8.0-rc2 https://launchpad.net/horizon/grizzly/grizzly-rc2 These are hopefully the last Grizzly release candidates for Swift and Horizon. Unless new release-critical regressions are found that warrant another release candidate respin, those RC2s will be formally included in the common OpenStack 2013.1 final release next week. You are therefore strongly encouraged to test and validate those tarballs. Alternatively, you can grab the code at: https://github.com/openstack/swift/tree/milestone-proposed https://github.com/openstack/horizon/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it on Launchpad and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Only a few days left! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone Grizzly RC2 available
Hello everyone, Due to the renaming of the trust extension and a response backward compatibility issue, we created a new Grizzly release candidate for OpenStack identity (Keystone). You can find the RC2 tarball and the list of fixed bugs at: https://launchpad.net/keystone/grizzly/grizzly-rc2 This is hopefully the last Grizzly release candidate for Keystone. Unless new release-critical regressions are found that warrant another release candidate respin, this RC2 will be formally included in the common OpenStack 2013.1 final release next week. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/keystone/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it at https://bugs.launchpad.net/keystone/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Happy regression hunting, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] what is the difference between 2013.1 and grizzly?
Oleg Gelbukh wrote: Generally, grizzly-X is a milestone tag inside release cycle codenamed 'Grizzly'. Note that tagging scheme has changed between milestones 2 and 3 of 'Grizzly' release cycle, so you see 'grizzly-1' and 'grizzly-2' tags but no 'grizzly-3'. Milestone 3 of 'Grizzly' is tagged '2013.1.g3' instead. Looks like we won't see codenames in tags anymore in following development cycles. '2013.1.rc1' is a tag referring to release candidate 1 version, and you can expect 2013.1.rc2 and so on as well. Finally, '2013.1' is the official release version and it reflects that it is first release made during year 2013. Hope this helps and if I've mistaken, someone will correct me. That's correct. We recently changed the format of our tags (from grizzly-3 to 2013.1.g3), now that versioning is more closely related to tag names. Grizzly release candidates are therefore tagged 2013.1.rcX. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Cinder Grizzly RC3 available
Hello everyone, Due to incomplete removal of the rtslib dependency in RC2, we created a new Grizzly release candidate for OpenStack Block Storage (Cinder). You can find the RC3 tarball and the list of fixed bugs at: https://launchpad.net/cinder/grizzly/grizzly-rc3 This is hopefully the last Grizzly release candidate for Cinder. Unless new release-critical regressions are found that warrant another release candidate respin, this RC3 will be formally included in the common OpenStack 2013.1 final release next week. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/cinder/tree/milestone-proposed If you find a regression that could be considered release-critical, please file it at https://bugs.launchpad.net/cinder/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Happy testing, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Quantum] OpenStack Networking Grizzly RC2 available
Hello everyone, Due to a number of high-impact issues discovered in the first release candidate, including logging issues, we created a new Grizzly release candidate for OpenStack Networking (codenamed Quantum). You can find the RC2 tarball and the list of fixed bugs at: https://launchpad.net/quantum/grizzly/grizzly-rc2 Unless new release-critical issues are found that warrant another release candidate respin, this RC2 will be formally included in the common OpenStack 2013.1 final release on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/quantum/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at https://bugs.launchpad.net/quantum/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Happy regression hunting, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Cinder Grizzly RC2 available
Hello everyone, Due to a licensing issue around cinder-rtstool and a number of high-impact bugs in various drivers, we created a new Grizzly release candidate for OpenStack Block Storage (Cinder). You can find the RC2 tarball and the list of fixed bugs at: https://launchpad.net/cinder/grizzly/grizzly-rc2 Unless new release-critical issues are found that warrant another release candidate respin, this RC2 will be formally included in the common OpenStack 2013.1 final release on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can grab the code at: https://github.com/openstack/cinder/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at https://bugs.launchpad.net/cinder/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Happy regression hunting, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Keystone] OpenStack Identity Grizzly RC1 available
Hello everyone, Last but not least, OpenStack Identity (codenamed Keystone) just published its first Grizzly release candidate. It is available for download at: https://launchpad.net/keystone/grizzly/grizzly-rc1 Congrats to the Keystone crew. Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as Keystone 2013.1 final version on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/keystone/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/keystone/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. The Keystone master branch is now open for Havana development, and feature freeze restrictions no longer apply. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Technical Committee Nominations are Open
Monty Taylor wrote: Now that the TC elections have ended, we now have three at-large seats open. https://wiki.openstack.org/wiki/TC_Elections_Spring_2013 Mar 15 - 21: Open candidacy to directly-elected TC positions Reminder: Just a few hours left to self-nominate yourself ! -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Glance] [Swift] RC1 available for Grizzly OpenStack Image service and Object Storage
Hello everyone, Next projects to publish a release candidate in preparation for the Grizzly release are OpenStack Image Service (Glance and OpenStack Object Storage (Swift). The RC1s are available for download at: https://launchpad.net/glance/grizzly/grizzly-rc1 https://launchpad.net/swift/grizzly/1.8.0-rc1 Congrats to the Glance and Swift development teams! Unless release-critical issues are found that warrant a release candidate respin, those RC1s will be formally released as the Glance 2013.1 and Swift 1.8.0 final versions on April 4. You are therefore strongly encouraged to test and validate those tarballs. Alternatively, you can directly test the milestone-proposed branches at: https://github.com/openstack/glance/tree/milestone-proposed https://github.com/openstack/swift/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/glance/+filebug https://bugs.launchpad.net/swift/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Note that the master branches of Glance and Swift are now open for Havana development, and feature freeze restrictions no longer apply. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Horizon] OpenStack Dashboard Grizzly RC1 available
Hello everyone, Hot on the heels of Glance and Swift, OpenStack Dashboard (codenamed Horizon) also just published its first Grizzly release candidate. It is available for download at: https://launchpad.net/horizon/grizzly/grizzly-rc1 Congrats to Gabriel and all the Horizon team! Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as the 2013.1 final version on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/horizon/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/horizon/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Note that the Horizon master branch is now open for Havana development, and feature freeze restrictions no longer apply. We are expecting the last Grizzly RC1s (Keystone and Nova) to be published before the end of the week. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-009] Keystone PKI tokens online validation bypasses revocation check (CVE-2013-1865)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-009 CVE: CVE-2013-1865 Date: March 20, 2013 Title: Keystone PKI tokens online validation bypasses revocation check Reporter: Guang Yee (HP) Products: Keystone Affects: Folsom Description: Guang Yee from HP reported a vulnerability in the revocation check for Keystone PKI tokens. Those tokens are supposed to be validated locally using cryptographic checks, but the user also has the option of asking the server to validate them. In that case, the online verification of PKI tokens would bypass the revocation check, potentially affirming revocated tokens are still valid. Only Folsom setups making use of online verification of PKI tokens are affected. Folsom fix: https://review.openstack.org/#/c/24906/ References: https://bugs.launchpad.net/keystone/folsom/+bug/1129713 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-1865 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRSdTdAAoJEFB6+JAlsQQj9sUQAL0y9zV5xWHDhAFpfaUGobq6 n5TVeEEf3kb1CIYuVhX6vHuPl2CtoekMSX7MOLehiwmbxGw3B4G7DONZrWuxmzOT J9B9kwMew3K5lE3X4oYH3cHjkTC+ZsnlUBzNiJIXEAkBFaGLmCwbt2eCREBcKvU8 glaPKncO226Y85wMV+Sbe12qDX/82o6TydkcJglhdGF3AYI4813yGb/U41rkKUnq zlsg4Zaea4IFUe23fc9EchRDcgR1N+yfZf04+CKRymhvOcYzSLZDNxJpYN+jwzLy UcB3Jqak8FR0+w3k28bz41COUWtynrTy5FAoDgvGtLM2m1GedMygNKdMb1yERC9z ELWb0P1Z6qt5zZa6BORM185PJ9Dy5zQkOOOH1I7nWjnIa9wFzvbQBKHv5WPARWDu rdAM2I55JmGxo6qFJWK6QnpYI6o6PQjQ2s0FC/H2kCMgXPygURD/X101Y2lOFSZ7 P8OhTKoVYqZf5pImpKCbtm1GHWIpev7BkzWvsFpPhVz4ExHSTsmc1Mk2ugDGQrgO tCcF7Eo0eABepY4qVrSUi4euZvpFsWcjl7GzQ0WLCWyMUdPo9271ZfsgxfPxId7l CMgn2hgpGv5+yTDDg4p8NSqmUp5hSMo/i6zgDrL9XEn4qx5Rr8pNqV/vUhmYQmzV qQqwB3DR57T1eFMlGL7y =9dar -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Nova] OpenStack Compute Grizzly RC1 available
Hello everyone, Almost there... OpenStack Compute (codenamed Nova) just published its first Grizzly release candidate. It is available for download at: https://launchpad.net/nova/grizzly/grizzly-rc1 Congrats to all the Nova devs, who fixed 201 bugs (!) in 4 weeks. Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as Nova's 2013.1 final version on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/nova/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. The Nova master branch is now open for Havana development, and feature freeze restrictions no longer apply. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Cinder] OpenStack Block Storage Grizzly RC1 available
Hello everyone, The second project to publish a release candidate in preparation for the Grizzly release is OpenStack Block Storage (code named Cinder). The RC1 is available for download at: https://launchpad.net/cinder/grizzly/grizzly-rc1 Congrats to the Cinder crew! Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as the 2013.1 final version on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/cinder/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cinder/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Note that the master branch of Cinder is now open for Havana development, and feature freeze restrictions no longer apply. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] TC candidacy
Hi everyone, I'd like to run for reelection to one of the Technical Committee directly-elected seats. For those who don't know me, I've been handling release management duties for OpenStack since November 2010, a work currently sponsored by the OpenStack Foundation. My involvement is mostly around project coordination, keeping a global view and trying to anticipate issues as our development community grows even larger. I'm also heading the Vulnerability Management team, which handles incoming security issues reports. On the development side, I authored the rootwrap framework which is being used by a few of our projects, and whenever I find some free time, I'm working on improving it. I've been regularly elected by our community to the Project Policy Board and Technical Committee directly-elected seats for the last two years. I was heavily involved in the transition to our new governance, authored the Technical Committee charter, and have been chosen to chair it for the past 6 months. I think it's important that the Technical Committee contains representation from the horizontal functions within the project (Docs, QA, Infrastructure, Vulnerability management, Release management...), since each project is already represented by the seats granted for all PTLs. Over the last 30 months we grew from 2 projects to 10 projects, and I'm proud to be part of this community which successfully managed to handle growth and adoption while preserving our ideals of open design and open development. The challenges ahead of us include accommodating further growth, resist fragmentation, and maintaining efficiency and coherence as we grow well past Dunbar's number. I hope that you place me in a position where I can help us through those challenges. Thanks, -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Quantum] OpenStack Networking Grizzly RC1 available
Hello everyone, The first project to publish a release candidate in preparation for the Grizzly release is OpenStack Networking (code named Quantum)! The RC1 is available for download at: https://launchpad.net/quantum/grizzly/grizzly-rc1 Congratulations to the Quantum development team for reaching that milestone so early, and fixing 97 bugs in 3 weeks ! Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as the 2013.1 final version on April 4. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/quantum/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/quantum/+filebug and tag it *grizzly-rc-potential* to bring it to the release crew's attention. Note that the master branch of Quantum is now open for Havana development, and feature freeze restrictions no longer apply. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-007] Backend credentials leak in Glance v1 API (CVE-2013-1840)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-007 CVE: CVE-2013-1840 Date: March 14, 2013 Title: Backend credentials leak in Glance v1 API Reporter: Stuart McLaren (HP) Products: Glance Affects: All versions Description: Stuart McLaren from HP reported a vulnerability in the information potentially returned to the user in Glance v1 API. If an authenticated user requests, through the v1 API, an image that is already cached, the headers returned may disclose the Glance operator's backend credentials for that endpoint. Only setups accepting the Glance v1 API and using either the single-tenant Swift store or S3 store are affected. Grizzly (development branch) fix: https://review.openstack.org/24437 Folsom fix: https://review.openstack.org/24438 Essex fix: https://review.openstack.org/24439 References: https://bugs.launchpad.net/glance/+bug/1135541 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-1840 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRQfdoAAoJEFB6+JAlsQQj0g4QAL+tmSjDHukvwPZ1D72ClLIR NKV9ceVNT+qus1W5Og2GOKjnrib8X4qkoR/P/Wp+nEoWYosch4YTMvpxc8hamm9P OohMdT4RFxQut//ZR6sn/TC2qLgErovlZRMxBKA43sFqHNbirprF5b9A4fF7glp6 atPAAM7rIHTJDXHvE+a8Qe8qOPKJKP1pOXrSZDL94ZMPq6uAy/0M0v/r/++aAUHy Qr7p2ITuVepJ3IM9/sZ+RQ1PXFya0BGBpLBEgaotBmmOMI/FNbthS3PT8W1ywX0S gpgcBLiXMXoNsMZCmsLeYirzldaT+ZtqjOxYqZYiAjn5cIQ5XXjFPq8w9vlh83An 8IVnanVl4C1M4hnYo3sCeFsCnh5sLdM/LVnd19Wz1k1PHTCM7vrNtU0wqAMQFj2C BQqNMMcQvFZdEjvzYymlm365DP07DHOi/jgK59EWCfeaEHx4Vs4fL0a9nnoxs/fV 8SysPv4A3iAaXDOan+0s+T0dac2/KU2FBio0+cuvV4qASYWN5CHAR9/6icWJQ2qh InUWIqcgwcOqR6azhQHg/ARw7iNZtv+omVvVOYZu6HOiK4BDj8RkQmPyWsis/ekU 4Ez6AyKSDmRHtoR9w7GcM14xCrHyqFfbaGUp+qDI73NNGmbXXtXlVEO8/g2ywbKc F0k3S2Z5fLOPFeo9ll4C =BmKh -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Entering DST madness zone again
North America entered DST last Sunday (Europe will do the same on March 31), so we are entering DST / UTC time confusion again. Remember that all our OpenStack online meetings are expressed in UTC time (which does not have DST nonsense), and doublecheck what that means for you using tools like: http://www.timeanddate.com/worldclock/fixedtime.html?hour=21min=0sec=0 For our North American friends, that probably means meetings are occuring one hour later than last week. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Feb 26)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC Tuesday last week. Here is a quick summary of the outcome of this meeting: * The TC approved the graduation of the Ceilometer project (to be integrated in common Havana release) See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-02-26-20.03.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Grizzly-3 development milestone available (Keystone, Glance, Nova, Horizon, Quantum, Cinder)
Hi everyone, The last milestone of the Grizzly development cycle, grizzly-3 is now available for testing. This milestone contains almost all of the features that will be shipped in the final 2013.1 (Grizzly) release on April 4, 2013. This was an extremely busy milestone, with 100 blueprints implemented and more than 450 bugfixes overall. You can find the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/grizzly/grizzly-3 https://launchpad.net/glance/grizzly/grizzly-3 https://launchpad.net/nova/grizzly/grizzly-3 https://launchpad.net/horizon/grizzly/grizzly-3 https://launchpad.net/quantum/grizzly/grizzly-3 https://launchpad.net/cinder/grizzly/grizzly-3 Those projects are now temporarily feature-frozen (apart from already-granted exceptions) as we switch to testing and bugfixing mode in preparation for our first release candidates. Please test, try the new features, report bugs and help fix them ! Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Grizzly-3 development milestone available (Ceilometer, Heat)
Thierry Carrez wrote: The last milestone of the Grizzly development cycle, grizzly-3 is now available for testing. This milestone contains almost all of the features that will be shipped in the final 2013.1 (Grizzly) release on April 4, 2013. And with perfect sync now, our two grizzly-incubated projects, Ceilometer and Heat, also have their grizzly-3 milestone available: https://launchpad.net/ceilometer/grizzly/grizzly-3 https://launchpad.net/heat/grizzly/grizzly-3 Happy testing and bugfixing! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Grizzly-3 development milestone available (Keystone, Glance, Nova, Horizon, Quantum, Cinder)
Martinx - ジェームズ wrote: What is the status of Openstack Grizzly-3 Ubuntu packages? Can we already set it up using apt-get / aptitude? With packaged Heat, Ceilometer and etc? Which version is recommended to test Grizzly-3, Precise (via testing UCA), Raring? Is Grizzly planed to be the default Openstack for Raring? I suspect it will take a few days for grizzly-3 to appear in Ubuntu, as the tarballs were cut a few hours ago. As far as I know, Grizzly is indeed the planned default OpenStack for Raring. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Swift]A design draft of Storage Quota
Alex Yang wrote: Storage Quotas Design https://docs.google.com/document/d/1b5hkT_E8PyzaAPjNImW0SF-yyh8vGrN_DNjMChol4_Q/edit This is the design draft of Storage Quota. Implementation of this design is https://github.com/AlexYangYu/StackLab-swift/tree/dev-quota Looks like a discussion that should have happened on openstack-...@lists.openstack.org, since it is about future development rather than the current state of affairs. -- Thierry Carrez (ttx) On-topic mailing-list police ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] security releases
Matthew Thode wrote: Is there any plan to have security releases for the supported versions of the various Openstack components? Like having a 2012.2.3.3 for keystone (the last number being the security release). We provide hotfixes in the advisories, and the fixes are included in our next source code point releases (2012.2.4). Most distributions provide packages which include recent security fixes. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Feb 19)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The TC approved the graduation of the Heat project (to be integrated in common Havana release) * The TC considered the suggestion of the Board of Directors to hold a common meeting on April 14. It's difficult to predict how many TC members will be able to make it (some members already have conflicting plane tickets), especially considering that almost all of the TC members will be renewed in upcoming elections in March. If confirmed on Sunday, the joint meeting should be very optional. Alternatives include a short meeting during one of the mornings (+ breakfast) or evenings (+ dinner) of the Summit days (outside regular summit hours). See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-02-19-20.02.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-004] Information leak and Denial of Service using XML entities (CVE-2013-1664, CVE-2013-1665)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-004 CVE: CVE-2013-1664, CVE-2013-1665 Date: February 19, 2013 Title: Information leak and Denial of Service using XML entities Reporter: Jonathan Murray (NCC Group), Joshua Harlow (Yahoo!), Stuart Stent Products: Keystone, Nova, Cinder (see note) Affects: All versions Description: Jonathan Murray from NCC Group, Joshua Harlow from Yahoo! and Stuart Stent independently reported a vulnerabilities in the parsing of XML requests in Python XML libraries used in Keystone, Nova and Cinder. By using entities in XML requests, an unauthenticated attacker may consume excessive resources on the Keystone, Nova or Cinder API servers, resulting in a denial of service and potentially a crash (CVE-2013-1664). Authenticated attackers may also leverage XML entities to read the content of a local file on the Keystone API server (CVE-2013-1665). This only affects servers with XML support enabled. Note: The vulnerabilities are actually in the various affected Python XML libraries, but we provide OpenStack patches working around the issues. Grizzly (development branch) fixes: Nova: https://review.openstack.org/#/c/22309/ Cinder: https://review.openstack.org/#/c/22310/ Keystone: https://review.openstack.org/#/c/22315/ Folsom fixes: Nova: https://review.openstack.org/#/c/22312/ Cinder: https://review.openstack.org/#/c/22311/ Keystone: https://review.openstack.org/#/c/22314/ Essex fixes: Nova: https://review.openstack.org/#/c/22313/ Keystone: https://review.openstack.org/#/c/22316/ References: https://bugs.launchpad.net/nova/+bug/1100282 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-1664 https://bugs.launchpad.net/keystone/+bug/1100279 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-1665 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRI5+DAAoJEFB6+JAlsQQj2fQQALLE9GEOIRGcj9gXXQ5mDS3l /CWI6ljTlVWxXy143lAUbkpvW0AHx0S6wVU38Hh/wS6D3u4JpxC2lERcI6KB7XyF R6F7qWzdwulh+0GX9n+8rO0qLVkqhB6hn3bCVUKu20N+cromJHsSgzDU6lvVlUAU dwc9eFWmg2d7bpESUdltDo9yEnz0jXxzOpCseC5/zfSo5RnJU1Oi4ZaiXPzbRqqb bQzKRGevLddHAMKJnKrYvpg5471LQ8bC7rMYwq44c4HH0+ZhwQVgwyBxdeyNGISI kJ1LhTGlDdTN1SBV3QDc0//pai2tQtcY96sQJ+1FWl9wrAMft+hSyCmRlsX2O4O1 zbN/iUEVmZRP1/JuD8tk+TDUlBdTSZai3pV9bVlRQ7GWUKSreDI38T87d+ZZe0Uz f63hafBSKGqQ/GD8s5HnJopvGK1vY2zgiNuORJc5PH8iPo/75YVRM3Ct6lFwooIe uPow6AbydISEVUbsK1AcLESQ6Uq4CufsNUColi1o+2PRlc2/Jt/ZXaFx2LfsE6ka m6cXJMIZZ6Mrz6ogtYnEYDkzPPQ7/oLXzVxoS3NCoh/LLxs838eqiAZ+mVVboAaO LOARFrqYw8wfg45JLqQ2mb/Oe10hPZdMwc+lQa2ccDYLBJXkrMKz7vHW8W47bM1H i5g9RJ8pkA5wFKxBgfKj =pNuW -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-005] Keystone EC2-style authentication accepts disabled user/tenants (CVE-2013-0282)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-005 CVE: CVE-2013-0282 Date: February 19, 2013 Keystone EC2-style authentication accepts disabled user/tenants Reporter: Nathanael Burton (National Security Agency) Products: Keystone Affects: All versions Description: Nathanael Burton reported a vulnerability in EC2-style authentication in Keystone. Keystone fails to check whether a user, tenant, or domain is enabled before authenticating a user using the EC2 api. Authenticated, but disabled users (or authenticated users in disabled tenants or domains) could therefore retain access rights that were thought removed. Only setups enabling EC2-style authentication are affected. To disable EC2-style authentication to work around the issue, remove the EC2 extension (keystone.contrib.ec2:Ec2Extension.factory) from the keystone API pipeline in keystone.conf. Grizzly (development branch) fix: https://review.openstack.org/#/c/22319/ Folsom fix: https://review.openstack.org/#/c/22320/ Essex fix: https://review.openstack.org/#/c/22321/ References: https://bugs.launchpad.net/keystone/+bug/1121494 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0282 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRI7nbAAoJEFB6+JAlsQQjGHgP/2yHBH4Yvzl3Q0P4oMr2Vskb 9xroi6sEQTgP/KaidIiV2lORdgSqYZZlylW3EbHnR1Io9natqCLfYkkEdpagTUxM WcYXAJtBHbHN+hpeGiYojPsV1LmgIX81UrausX1k5U1ZtFkvOhrfhcXWPOozREkM WwhYjaGl14dmIusE7h0uY7VNTiQMI9LAft18OfJMNFTwA/FmkxlPO/Jea8CUwDIl LSLv+MRFw2M01TnsAYlnFsa9O7175q2DpNPCqXYjh38ewNBJHuArtuASkA7hHrMA wYUzAS3lho9WuGVG/GwZk1V//GQhpzn/VWxRCmuOS3tpwTksbkXF36kwOnP5Vu5N uo9jLBAovHIqfr0QGXGYMXA9Bu9jW5geUIuDNvpKkAFIiQVS3JcDWsqsu7otgjHY HKUKmYF66BAJmmaM7aXPswGs61B6F3SLIZCneOp9N8PnT3PCR57++zMEjEWBYuLw E4BDKPa1k2Q822hxWizhXAmkfc5t+AVk2kKPa9a5sMY2oNNrqtRR4+jMjXiS9CmU gQs9VbXrmMy577zcCkzj7ci7fY0iFUtHW7PhFKUpHf2Mpr2/vLwc4p8g5da8bTwU 2swDuJ/KPsd66oEYjQW0CGBymMTkmbZWUX4InAj1ZynESW46cb/CAaS8oGk2I6dC F3MMfAjNkfhO9srLLNoC =fWOa -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Feb 12)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC on Tuesday. Here is a quick summary of the outcome of this meeting: * The TC approved the special motion on the incubation process evolution: 1. Incubation is the process managed by the TC through which a project becomes part of the co-ordinated, integrated OpenStack release. 2. Projects which are part of a co-ordinated release should be referred to as Integrated in that release. Previously this was one of the meanings of the term Core. 3. Projects apply to the TC to join Incubation. Their incubation request is assessed by the TC on the basis of the project's technical maturity and the appropriateness of its scope. 4. At the end of every development cycle, before PTL elections are held, the TC carries out an end of cycle graduation review of the projects currently in Incubation. Projects will graduate from Incubation if they are considered mature, stable in design, complementary in scope and well aligned to the development cycle and processes. Graduating projects will be part of the next development cycle and fully integrated in subsequent releases. Under the current 6 month release cycle, this means a graduating project will be Integrated in the release 8 months after the TC deems it ready to graduate from Incubation. 5. The TC charter[1] will be updated to replace the word core with integrated as per (2). The effect of this change will be that PTLs for projects graduating from Incubation will be automatically granted a seat on the next TC. 6. The following sentence will be removed from the TC's charter: The TC recommends projects for Core status addition, combination, split or deletion of the Board of Directors, which has the sole authority to approve them. The process for assigning projects core status is still under discussion, but we do not anticipate the process will be triggered by a recommendation from the TC and, therefore, this statement is inaccurate and should be removed. Further TC charter changes may be recommended in future to reflect the new process for core status. [1] http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee * We started the end-of-cycle graduation review for Heat and Ceilometer, covering statements of readiness and release process alignment. This review will continue next week. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-02-12-20.03.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-003] Keystone denial of service through invalid token requests (CVE-2013-0247)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-003 CVE: CVE-2013-0247 Date: February 5, 2013 Title: Keystone denial of service through invalid token requests Reporter: Dan Prince (Red Hat) Products: Keystone Affects: All versions Description: Dan Prince of Red Hat reported a vulnerability in token creation error handling in Keystone. By requesting lots of invalid tokens, an unauthenticated user may fill up logs on Keystone API servers disks, potentially resulting in a denial of service attack against Keystone. Grizzly (development branch) fix: https://github.com/openstack/keystone/commit/8ec247bf61be0e487332d5d891246d2b7b606989 Folsom fix: https://github.com/openstack/keystone/commit/bb2226f944aaa38beb7fc08ce0a78796e51e2680 Essex fix: https://review.openstack.org/#/c/21216/ References: https://bugs.launchpad.net/keystone/+bug/1098307 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0247 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRETGUAAoJEFB6+JAlsQQjbC0QAIzjY1gNe/Lr2X+xDOvz+q2v 7O6Tn2ZV3X1/fgdVbicl4CVnNzkb3mbG1/pIEl7FbpSFfY6a3a8leJZD7u9bKB6z M4xNGXITGJoT7HBo8ABvDH4X6p5oA/LDkuCZVotY4SHa5xIYRcQk884DbnIYoGe7 zXEek352gHgX7m0DmABm8Pz8E+IpyFIp8rdPEv4w9EeVDJmjhZvcgsMhKZmNahph DyBMDvdGY7nXeurzI43tMdWHkqYCljq1qagLqzNxjXJj796FNixUdwnBfmvkRuDI XvNOGQEnwWMdwRhHgQm9C6o9Y8OYnA2XXLxjKhYuNOYT09c2ZPqhITuT1Aka8eg4 Xnqt6OnGLhA8qq0zYfRPGAZFXghQ20NqSDU4CaZntYS9bFUZjQegnKA9qmo2bdJp TbtE/UoZgDAxAvm5n0myHuT2nw75RCM0FWvbKA6VpgK2qikx77rK6/Y5M68F1288 hj7qxMUrbsj0aNBPoWkgpUdIzH3oLsvVq4tRxhSUGj06UIOtXo9QVpxRjmOU46eM HKKL0n2Gfmi+kXgJfUdlGeQjlYUnNIx4pljn0RHRwyc5nLGdLUTy6ufnRclYRKSY roS2qlrR+gDkKeHP3JS1zcdFblg/VKrAK5IN+JIeKRbZ+l/g2ghFemoVYjdduR3E IRB0CC4khRi7njgBdDl1 =CzsK -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] (no subject)
Xiazhihui (Hashui, IT) wrote: 1.I want to know if grizzly-3 is the last of Grizzly? Will it have a grizzly-4? No there won't be another milestone. The release schedule appears at: http://wiki.openstack.org/GrizzlyReleaseSchedule The release cycle is explained at: http://wiki.openstack.org/ReleaseCycle The developer section of this page contains a few other useful pointers: http://wiki.openstack.org/HowToContribute 2.I hava a cinder driver, if I want to commit it in grizzly-3. What's the deadline of the codes committing? Should the code be approved by PTL before 2013-02-21 ? The proposed change needs to be merged before the end of the day on February 19 (when we branch for grizzly-3 delivery). That means gathering necessary code review approvals before then. This can take time, so code should be submitted asap. 3.Grizzly will public in April 2013, can I commit my blueprint codes from 2013-02-21 to April 2013? No, Feb 19 is Feature Freeze, so if you don' tmake it by then, your feature will be part of the next release (Havana) instead. Engaging early with the developer community (and the project PTL) is the key to success. Ideally features would be presented to the design summit and implemented in the months after, to be integrated in the release at the end of the 6-month cycle. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-001] Boot from volume allows access to random volumes (CVE-2013-0208)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-001 CVE: CVE-2013-0208 Date: January 29, 2013 Title: Boot from volume allows access to random volumes Reporter: Phil Day (HP) Products: Nova Affects: Essex, Folsom Description: Phil Day from HP reported a vulnerability in volume attachment in nova-volume, affecting the boot-from-volume feature. By passing a specific volume ID, an authenticated user may be able to boot from a volume he doesn't own, potentially resulting in full access to that 3rd-party volume contents. Folsom setups making use of Cinder are not affected. Folsom fix (included in upcoming Nova 2012.2.3 stable update): http://github.com/openstack/nova/commit/317cc0af385536dee43ef2addad50a91357fc1ad Essex fix: http://github.com/openstack/nova/commit/243d516cea9d3caa5a8267b12d2f577dcb24193b References: https://bugs.launchpad.net/nova/+bug/1069904 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0208 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRCCZCAAoJEFB6+JAlsQQjDSYQALrBUhPwUbxFtVrTSGhjDK7A Donl1ykZy1CtsykGiXa5NuREw+xtoKZl/NteLDVRo/C0tWcGe2L2rk5FxMboKdRu 2I0CXXQ65liHySvZqzlZE6M5TfAhGWCJBOpZArbF6PcB/ZP/F/a/2/BU6HbHonSn g58Lq8wKK2JErU5djee9B22wkUTlxiZv2JThOGr/VRoR2F3Zxdmd3UbBC+9Db5tg OQMBHlGLXgSCvUZBkzMZwyfxvovf6fpTlmFU/8Ff9OWA4fMxtpsybIcD9BoaLZAd 2U2/f5qoIbh3soZGF5DH1ucVym0js8NtAf9E+9FVzg2SfHX0sF8Qo1sLowEb/43d n8WdBQBYLzfLjKqDGkvNUjfhDHkzO6ujekUQCdMtADBk1tBI6IdfSzyJkhMWXF5S Rs3Fpkr1gkXq0xuNf9UQPuA1op2TiBxKa5Z8svOfXnHa7m/NOsYHJ3S4hL5e9E6S osJ5LlZDvX+xUGIzRTpViAx0YGwNykRlInhtLJrAoKLWWV/3EA9ap4Bl6XB/ZFsO UbUeCDGpepAianOnx2S6p7JhERkcT7R0DHVWI7b5U5hPemt1B6bfkTzgwpwIstDv XtSwzVvUuNMfDUG2bMSfXmPqdzZBwdh4iKjIJzT5PecFQ5qBOJOvhF5/aCB2UtI2 LaVsd1b7v/7C3ln4j/bB =eX8i -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Poll: H release cycle naming
Results are in: 1. Havana (120) 2. Hood (79) 3. Harbor (43) 4. Hatfield (41) Havana it is. https://launchpad.net/~openstack/+poll/h-release-naming -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2013-002] Backend password leak in Glance error message (CVE-2013-0212)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2013-002 CVE: CVE-2013-0212 Date: January 29, 2013 Title: Backend password leak in Glance error message Reporter: Dan Prince (Red Hat) Products: Glance Affects: All versions Dan Prince of Red Hat discovered an issue in Glance error reporting. By creating an image in Glance by URL that references a mis-configured Swift endpoint, or if the Swift endpoint that a previously-ACTIVE image references for any reason becomes unusable, an authenticated user may access the Glance operator's Swift credentials for that endpoint. Only setups that use the single-tenant Swift store are affected. Grizzly (development branch) fix: http://github.com/openstack/glance/commit/e96273112b5b5da58d970796b7cfce04c5030a89 Folsom fix (included in upcoming Glance 2012.2.3 stable update): http://github.com/openstack/glance/commit/96a470be64adcef97f235ca96ed3c59ed954a4c1 Essex fix: http://github.com/openstack/glance/commit/37d4d96bf88c2bf3e7e9511b5e321cf4bed364b7 References: https://bugs.launchpad.net/glance/+bug/1098962 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0212 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJRCCvqAAoJEFB6+JAlsQQj9scP/1bQzhQ5lA/jNoPIPMlUKOr4 NlrT9+QA6pF3xOjTQeyViTTUfMn1YHdOTS8bi/NeSlL3UuEhpdCb59APwqmZva3u Tx+so6L3nc5qNRdDAAr6oNBYmD08T41ceLpzjv9BbTgPxD4gUCg9WeySBAa+I7MU 1w1hvhObhQWZ8Xvqf/2tKTrMpGuJOS/0aoMSQUMqFR47moyYgBznNT6J3FaC3haE jRh4RSv7XKN2MU0Cv05m/txXNUTP6rtl+qAiGW9UZvhTHY/kafaJLi/HuGkmANf0 fkuoKL5VxFYoIbHDlJ+ymPUz/jgoZJNkvvmS5mQH7YFBdgAvzAIAYJ4jk8uOMMmo AHqaVdfZYCWRP6pMDzjnU5EGhRrgt2RafWsnU8MyYePrF3G8dcikvQlIki+PlmPT +zXjPoIsirFJh3XSTRNbUDwIww6AuBbhxgJD78NhQY/12MC5zELOasWcpTKPyvLs HTIe8AbVLf5Z0blZdUZHGlzFBQlgPU3ydIjY1UStWPYNCQs2hTrtoq9y68LmDzix jRQ3jmKhMGsLwlrcskSyD/1qGGD6NNPRJwME7pXspy7mBlN0LS9OLRwhYHTzNGwx YTSKhy12xooqYkaJncZEduTBKwMJLMwk/HZxD7KRuKPM7xoK64mkyz/03rUsQORj na6Kqw9rcPfJG0jfh3/c =PyUp -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Progress on wiki migration to Mediawiki
Thierry Carrez wrote: Ryan Lane wrote: Image location is fixed and the redirects are also in. I still have issues with image location. Everything works now. Beautified main page is up at: https://wiki-staging.openstack.org/wiki/Main_Page So my part is done :) -- Thierry ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Poll: H release cycle naming
It's that time of the year again... As is the tradition, we'd like the help of the community to help select the code name of the next release cycle of OpenStack. The Technical Committee narrowed the list of valid candidates to 4 names, and we'd like you to pick the one you prefer. So what will it be ? Hood, Havana, Harbor or Hatfield ? Please head to: https://launchpad.net/~openstack/+poll/h-release-naming to let us know what you prefer ! Poll ends Tuesday, January 29, 20:00 UTC. Note that you need to be a member of the ~openstack group in Launchpad to be able to vote, but all people on this list already are. -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Poll: H release cycle naming
Adam Young wrote: I think we have overlooked the most obvious answer: [...] To keep the single-choice poll efficient, the Technical Committee preselected 4 finalists from the list of 35 (!) valid options. Sorry your preferred option didn't make it. -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Progress on wiki migration to Mediawiki
Ryan Lane wrote: Image location is fixed and the redirects are also in. I still have issues with image location. See https://wiki-staging.openstack.org/wiki/File:Openstack-compute-icon.png or https://wiki-staging.openstack.org/wiki/File:Compute.png Everything looks ok, except access to image data returns 404 at: https://wiki-staging.openstack.org/w/images/2/25/Openstack-compute-icon.png https://wiki-staging.openstack.org/w/images/d/d5/Compute.png Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Progress on wiki migration to Mediawiki
Anne Gentle wrote: - Make the landing page mo' better. (Thierry Carrez, ttx) While we won't be able to have the migration make the columns on all the pages lovely, he can make the first page beautious again. I pushed an optimized page at https://wiki-staging.openstack.org/wiki. There is still an issue with uploading images (404 on whatever you upload) so I could not add those. Would be great to fix that before we flip the switch. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova root wrapper understanding
Kun Huang wrote: Thanks, Thierry Carrez. Your explanation is easy to understand. I have got why we need such a mechanism. BTW, is root-wrap a general or popular way to keep security? I have no experience on security, but I have heard the /root /should be banned because of security. Ideally, should we ban /root /in nodes and just use root wrapped /nova /user for tasks in need? Ideally, we should run all services as an unprivileged user (nova). In reality, given the low-level tasks generally needed to bootstrap infrastructure resources, it's difficult to achieve. So we should strive to only escalate when really needed, and filter properly to ensure escalation is limited. Rootwrap provides a framework for that filtering. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova root wrapper understanding
Kun Huang wrote: In this wiki, http://wiki.openstack.org/Nova/Rootwrap, the part of security model results in This chain ensures that the nova user itself is not in control of the configuration or modules used by the nova-rootwrap executable. I understand that chain but I`m confused with this conclusion. That chain means that a nova-rootwrap executable runs safely under root-control. In another word, the program nova-rootwrap runs is protected by root, and it cannot be influenced by other users. But that conclusion implies that the insecurity model is /nova/ user is in control by someone. This is what I'm confused with. The goal of the rootwrap (used by Nova, but also Cinder and Quantum) is to allow openstack services to run some commands as root, while running the remaining of the code as an unprivileged user. This limits the amount of damage that a security hole in openstack may inflict on the system. Imagine a security hole in Nova that enabled an attacker to execute arbitrary code. That code would be executed as the nova user, which limits the amount of damage on the rest of the system. The trick is to allow the nova user to run /some/ code as root, without letting it execute /anything/ as root. Rootwrap is just a mechanism to provide limited privilege escalation. The rootwrap chain mentioned in the wiki ensures that only the root user controls what the nova user can execute as root. If you let the nova user itself in control of what the nova user can execute as root, you end up with around the same security as if you were running as the root user directly. Now, the privilege escalation limitation is only as good as the precision of the rootwrap filters you use. It's pretty good for nova-api nodes, which are basically not allowing anything to be run as root. It's not nearly as good on nova-compute nodes, where we still use pretty liberal filters that could use some work. We could also get rid of the code that requires most of the run-as-root stuff, in particular the pre-boot file injection mechanisms (evil! use boot-time customization instead!). Hope this clarifies, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova root wrapper understanding
Daniel P. Berrange wrote: FWIW, if you've got libguestfs available, the file injection code does not require any rootwrap usage. Ironically the config drive stuff now does require root if you configure it to use FAT instead of ISO9660 :-( My issue is that we enable a very permissive compute.filters just to care for the case where you use localfs-style injection. We generally hurt the security model to care for a specific less-secure deploy option. What we /could/ do is split compute.filters so that you have a specific filters file for localfs-style injection commands. Deployers would enable that specific file in the case they use localfs-style injection. It's tricky because you can't really trust nova to tell you which option it runs with, so you have to rely on deployers enabling the localfs-option to also enable that specific filters file, which is a bit of a configuration nightmare and very error-prone. Alternatively we could rip out localfs-style injection altogether. I have a general desire to make it such that you can run with KVM and Nova without requiring rootwrap for anything. last time I looked the three general areas where we required root wrap were networking, storage and file injection. My recent refactoring of file injection addressed the latter by using libguestfs APIs instead of libguestfs FUSE. Networking is mostly solved if using newest libvirt + Quantum instead of Nova's own networking. Storage is something that cna be addressed by using libvirt's storage APIs instead of running commands directly. That's my goal too. Ideally devs would think twice before adding any new run_as_root=True command. Every command we add lowers the security model around openstack. It's very easy to add one, and very difficult to remove one once it's in. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Grizzly-2 development milestone available (Keystone, Glance, Nova, Horizon, Quantum, Cinder)
Hi everyone, The second milestone of the Grizzly development cycle, grizzly-2 is now available. It's a significant step toward the final delivery of OpenStack 2013.1 (codenamed Grizzly), scheduled for April 4, 2013. You can find the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/grizzly/grizzly-2 https://launchpad.net/glance/grizzly/grizzly-2 https://launchpad.net/nova/grizzly/grizzly-2 https://launchpad.net/horizon/grizzly/grizzly-2 https://launchpad.net/quantum/grizzly/grizzly-2 https://launchpad.net/cinder/grizzly/grizzly-2 Features may be added until the next milestone, grizzly-3, which will be delivered on February 21st. Let's all make it awesome ! Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Jan 8)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The TC approved the new policy on Distro Python 2.6/3.x support: OpenStack will target its development efforts to latest Ubuntu/Fedora, but will not introduce any change that would make it impossible to run on the latest Ubuntu LTS or latest RHEL. * We also reported on the latest progress from the joint committee for the future of Incubation and Core, as well as started discussing potential changes in TC membership to accommodate future growth in the number of projects. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Cinder] cinder-agent
John Griffith wrote: On Fri, Jan 4, 2013 at 11:39 AM, Akira Yoshiyama wrote: I think Cinder should have its own client service 'cinder-agent'. There are many benefits: This is something I've thought about a little bit but to be honest it's been very low on my priority list. I've be very interested in pursuing the idea further and getting more input/feedback from the community. I think there are some significant benefits to this for NTT and a few other end users as well as obvious wins for those vendors with storage drivers in Cinder. It's also something that should be discussed on the openstack-dev mailing-list, since it's a bit forward-looking (discusses future development rather than current state). Thanks, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Wiki content imported into MediaWiki - please check
Ryan Lane wrote: [...] * TableOfContents: we used that macro on a lot of pages -- but I guess we could abandon them This is a simple search and replace. I can install an extension to let us search/replace across all pages. MediaWiki creates a TOC by default if a page has three headings or more. It can be forced using __FORCETOC__. It can be force removed using __NOTOC__. That's probably sane by default. Thanks for the pointer. I fear we are more than just a couple of days away from being able to migrate content in a mostly agreeable way, but you're the expert :) I meant the content being agreeable, not the style and such. Wiki migrations often take months, not days. After the switchover we can have a sprint to fix the most glaring issues. That said, I'm willing to push the migration back if needed. Waiting on a theme is worth pushing it back for. I think it would be good to have the following set up before we move: * OpenStack theme -- volunteers ? * Cleaned up main page -- I may have a shot at this one * Root-served articles (to avoid breaking links) -- Ryan * Access control on protected pages -- Ryan Then we can work post-migration (in a sprint or in the following days/weeks) on various conversion issues on sub pages: * Table issues * Link issues * Image inclusions * etc. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Wiki content imported into MediaWiki - please check
Ryan Lane wrote: I've just finished importing the content from the MoinMoin wiki into the MediaWiki instance. Please check the content: https://wiki-staging.openstack.org/wiki/Main_Page [...] Also note that the migration script doesn't map from MoinMoin to MediaWiki perfectly and we'll need to clean up some of the content manually. We'll need to create some templates for missing features too (like columned layout). The most obvious issue is how ugly the new main page is :) The loss of image inclusion and columns transformed an admittedly not perfect page (disclaimer: I authored it) into something unreadable and very unwelcoming. Note that it's probably the only page that uses column layout, so maybe we can just special case the main page rather than write a generic column-handler. Image inclusion however is a bit more problematic, as it's being used in several pages (like http://wiki.openstack.org/Documentation/Translation/Status) that are now broken. The second most obvious issue is the loss of the OpenStack theme on all pages: it would be good to theme the wiki before we complete the transition. Other issues to watch for before completing the transition: * Broken table layouts, and no more cell background colors: See examples at https://wiki-staging.openstack.org/wiki/GrizzlyReleaseSchedule or https://wiki-staging.openstack.org/wiki/Releases * URL: The new wiki URL appear under a wiki/ subdirectory: https://wiki-staging.openstack.org/wiki/Projects -- would be great to make sure that once the migration is completed they can still be accessed from previous URLs (http://wiki.openstack.org/Projects) so that we don't have to change URL pointers from other sites. * TableOfContents: we used that macro on a lot of pages -- but I guess we could abandon them * Protected pages: A limited number of pages are protected in the old wiki (mostly governance pages, main page and list of official projects) to avoid random edits -- will this feature be kept ? We're going to leave the wiki up for a couple days in this state. If the content is mostly agreeable and we decide to press forward, I'll migrate the data again and we'll replace MoinMoin. I fear we are more than just a couple of days away from being able to migrate content in a mostly agreeable way, but you're the expert :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Blueprint proposal: Drop setuptools_git for including data/config files
Thomas Goirand wrote: On 12/18/2012 12:17 AM, Thierry Carrez wrote: Thomas Goirand wrote: [No pun intended, but it'd be nice if stackers had a bit more consideration for our work in Debian, and stop thinking only with Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, ... in mind.] There is nothing Ubuntu-specific in this. And nothing bzr-specific either. Fedora uses the same process with success. I agree we can improve the tooling so that it's a bit more flexible to various use cases, but don't make it a question of supporting only Ubuntu vs. the rest of the world. It's been a long time since we only supported Ubuntu. Cheers, Hi Thierry, It's a shame you only reply about this, and now I regret writing these lines. That was in brackets, and not so important. The rest of my post was more valuable, IMO. The technical part of your post is being addressed on openstack-dev, I saw no reason to cross-post or add to Mark's request for clarification. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Blueprint proposal: Drop setuptools_git for including data/config files
Thomas Goirand wrote: [No pun intended, but it'd be nice if stackers had a bit more consideration for our work in Debian, and stop thinking only with Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, ... in mind.] There is nothing Ubuntu-specific in this. And nothing bzr-specific either. Fedora uses the same process with success. I agree we can improve the tooling so that it's a bit more flexible to various use cases, but don't make it a question of supporting only Ubuntu vs. the rest of the world. It's been a long time since we only supported Ubuntu. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Packagers] Adding psutils as a dependency for nova
Michael Still wrote: Stand down. Padraig has suggested a better way. Also note that new dependency discussions are a better fit for openstack-dev. -- Thierry Carrez (ttx) Committee for the Usage of the Right Mailing-lists ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New build dependency on keyring
Ken Thomas wrote: Greetings all! I'm look into using keyring as a way to (optionally) remove clear text passwords from the various config files. (See https://blueprints.launchpad.net/oslo/+spec/pw-keyrings for details.) [...] This is a development topic, a better fit for the openstack-dev mailing-list. -- Thierry Carrez (ttx) Committee for the Usage of the Right Mailing-lists ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2012-020] Information leak in libvirt LVM-backed instances (CVE-2012-5625)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2012-020 CVE: CVE-2012-5625 Date: December 11, 2012 Title: Information leak in libvirt LVM-backed instances Reporter: Eric Windisch (Cloudscaling) Products: Nova Affects: Folsom, Grizzly Description: Eric Windisch from Cloudscaling reported a vulnerability in libvirt LVM-backed instances. The physical volume content was not wiped out before being reallocated and passed to an instance, which may result in the disclosure of information from previously-allocated logical volumes. Only setups using libvirt and LVM-backed instances (libvirt_images_type=lvm) are affected. Grizzly (development branch) fix: http://github.com/openstack/nova/commit/9d2ea970422591f8cdc394001be9a2deca499a5f Folsom fix (included in upcoming Nova 2012.2.2 stable update): http://github.com/openstack/nova/commit/a99a802e008eed18e39fc1d98170edc495cbd354 References: https://bugs.launchpad.net/nova/+bug/1070539 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-5625 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQx4DRAAoJEFB6+JAlsQQj5sEP/2osrfWvooWEeQbhnHGIp7yg GRR1BdPqqnBqBT4lzXp1B6O23l4LqSjKVC1X3r3zs2VqUcsZwTiJJz3FmPFlr0xZ 5BSSrg4GWo+If0atGqsWwOabTzuOZqCoFe16uXghtBwjmceZBjUOhra4mfnW+VtO xVc9eXiREEnxkHFHVPVuNnAxdxgoYin8Nw0NaOs+uZ9ehTjv2h0/81FNGNy3Rw5Y TPJOq3YFrneAK5GEL/srhV+3V6LnRKXqlPIhFbw5wqO+WlHZWOHnayL/hQZaivdF gYiuaTkwU2d6yKbasy+q9flreylZbtllcj1p3IGvoAFbTSA3u2l3AeElqnx6D+ak ULxIpLQGlBzabiUDLpSe+9t/gv7bY7qcf+Ec1u6DsgRpN/GhHHwBKykzoQwvTPS/ Of+CfmJj39NJarepUHMO7GMVUu/BYkQm4EnfPAnP8X8Gz5/0xJjo2ue7vnx8yuxC M7CPxWx3pZanC98n1omF5GvRlcdWECmbcP7NYynXhrROOw8mgXAs+Eh77mD94flk iZULo5fOJDShCVY+LmekzHix9WNRQSWxceAMYHrlNLo/H4zN5DWo063xgxYlSuNI +jfJ6DtqePjjG+c9tDcpVG9/OMxpyN8CKoWDSVWwdkTega3a7e1AAf9xEj0jT1jd OC2iQxz1crzjL1CV9z3J =CE4b -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Blueprint proposal: Drop setuptools_git for including data/config files
Sascha Peilicke wrote: Currently, the majority of OpenStack components make use of the Python module setuptools_git in order to install additional configuration files. This is basically the same functionality that the MANIFEST.in file (setuptools/distribute) provides, but automatic. Note: This is a development topic, it should (have) be(en) posted to openstack-dev to reach the appropriate audience. Please follow-up there. However, we recently discovered that this approach has issues from a packaging perspective. We weren't getting all the data/config files that the python package usually gets even though we were running the same commands: $ python setup.py build followed by: $ python setup.py install --skip-build We are building RPM packages from release tarballs (such as [1]), which of course don't include the .git directory. Therefore the setuptools_git approach can't do its magic, thus our package builds get wrong results. Having OpenStack components rely on setuptools_git at build time means we have to distribute the whole git repository along with the source code tarball. Of course this makes no sense, since it would increase the size of release tarballs dramatically and won't get shipped in distributions anyway.Therefore, we (and potentially other distribution vendors) would have to track these files manually in our RPM spec files. Some reviews have already been opened on the topic (admittedly before we discovered the real issue). Given the different outcome of each review it seems that not everybody is aware that setuptools_git is used or of what it does. https://review.openstack.org/#/c/17122/ (ceilometer) - this one got accepted before we knew what was going on https://review.openstack.org/#/c/17347/ (cinder) - abandoned until the situation is clarified https://review.openstack.org/#/c/17355/ (nova) - rejected So the better solution would be to stop using setuptools_git and just include all the data/config files that are meant to be distributed in the MANIFEST.in file. This is what every Python developer should know about and has the benefit of increased transparency about what gets installed and what not. We created a blueprint to track this [2]. Thoughts? A bit of history here: We used to rely on MANIFEST.in to list all files, but people routinely forgot to add new files to it. Apparently every Python developer doesn't know (or care) about this. The end result was that we discovered very late (sometimes after the release itself) that we built incomplete tarballs. As a quick search[1] shows, I have personally filed 27 bugs so far on the subject, so it's not a corner case. [1] http://bit.ly/TDim7U Relying on setuptools_git instead allows to avoid that issue altogether. The projects that adopted it became a non-issue. The projects that didn't adopt it yet are still a problem. I was about to push setuptools_git support to projects that don't use it yet. In summary, I would hate it if we went back to the previous situation. I'm not personally attached to setuptools_git, but any proposed replacement solution should keep its simplicity. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2012-018] EC2-style credentials invalidation issue (CVE-2012-5571)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2012-018 CVE: CVE-2012-5571 Date: November 28, 2012 Title: EC2-style credentials invalidation issue Reporter: Vijaya Erukala Products: Keystone Affects: All versions Description: Vijaya Erukala reported a vulnerability in Keystone EC2-style credentials invalidation: when a user is removed from a tenant, issued EC2-style credentials would continue to be valid for that tenant. An authenticated and authorized user could potentially leverage this vulnerability to extend his access beyond the account owner expectations. Only setups enabling EC2-style credentials (for example enabling EC2 API in Nova) are affected. Grizzly (development branch) fix: http://github.com/openstack/keystone/commit/9d68b40cb9ea818c48152e6c712ff41586ad9653 Folsom fix (included in upcoming Keystone 2012.2.1 stable update): http://github.com/openstack/keystone/commit/37308dd4f3e33f7bd0f71d83fd51734d1870713b Essex fix: http://github.com/openstack/keystone/commit/8735009dc5b895db265a1cd573f39f4acfca2a19 References: https://bugs.launchpad.net/keystone/+bug/1064914 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-5571 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQtjAkAAoJEFB6+JAlsQQj+4sP/0uKJHxXeCY3HcAdMUtkYP+5 QyQGnscOhlggr9iE3ifPWkiLALPbfVrdwp/nJr0psXiUnf60QX4Pfj63VJz23DSf 1Hk/Z3yY5oWmCCgT8/DMgw+SPhkn09YfS6f5KwuMR5zdEX345myp2MFcc1/mgNzx CfVKagHoCq8rrIhTjhAvyy5iwY/ZvbDFIgWKzgr3KCSm+76QuIqIoXHkdiCGYm4q OMfKEcS1WQZlmUddc54fR2g6kFY/sIsVKGdCtqJBqc6COU+MyUuhNvs7niXGK1Ep cU3U7tV6JCK58K70vgtQ0O5EWcDKm/Yfh5Sf/wmJTDwE2UxI8OGNEAzNJl/qxdEw iMUp/qRObtnN2t7pF2Rf7/ixZsTWSxpFToq6BZl4O4pghqQZQgZ9dGVgtSFkX8Tn crMjs8oWwtJuu1/paHje0O+9Y23NHMIdAg3ccjJUkC8MxfcnrxZkYd5XHZytecff iWPUWmm3ISFkOQQPuemah0vcu2Y+YvhjEY9b5nL2Ew6I/E4DeYxL1HwpeBA0lzrt w7nQgWCyf+ERz2g1liesuaSJ0CPBmKe93ji20kVvHTV9IRXmC3zK/SDhXtgultVo DmY/ovoUjTw9sg60CceTNXAUz4/4QbbUV79vFQ/06sThZ8t7ZW1kTfOrTSG6M4uw a557x0IhXfUedbbLCsE6 =+0zu -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2012-019] Extension of token validity through token chaining (CVE-2012-5563)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenStack Security Advisory: 2012-019 CVE: CVE-2012-5563 Date: November 28, 2012 Title: Extension of token validity through token chaining Reporter: Anndy Products: Keystone Affects: Folsom, Grizzly Description: Anndy reported a vulnerability in token chaining in Keystone. A token expiration date can be circumvented by creating a new token before the old one has expired. An authenticated and authorized user could potentially leverage this vulnerability to extend his access beyond the account owner expectations. Note: this vulnerability was fixed in the past (CVE-2012-3426) but was reintroduced in Folsom when code was refactored to support PKI tokens. Grizzly (development branch) fix: https://github.com/openstack/keystone/commit/38c7e46a640a94da4da89a39a5a1ea9c081f1eb5 Folsom fix (included in upcoming Keystone 2012.2.1 stable update): https://github.com/openstack/keystone/commit/f9d4766249a72d8f88d75dcf1575b28dd3496681 References: https://bugs.launchpad.net/keystone/+bug/1079216 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-5563 - -- Thierry Carrez (ttx) OpenStack Vulnerability Management Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQtjwXAAoJEFB6+JAlsQQj3cwP/3FUjqWBxAHgRTMWz2Df5JML DZIelkcq3kxSn05GCJ25FU5JyA3lWvqqoEsU4+SxytBTNAGYhDe8toSo74xU4PlU g3+A2V5oUMEJnyCS6ps7YMiLmd1unN3Fz/yrqxAZE7GRv+voD1l64+2IHK15bN7G WG+FxN3CgRK+pk+3MpPkaNLI1L9wTeYTPUgBdem+I7xhmLRsf5TBO1gqu3gHja1+ gvpWjezroWrVdAuqWFFsgzWf7LUZqZR/AqaWwS4DrHJ4LoD+ruHXNGvGyg1BQg8d IhqgAhBSdndlaJWTr6fj2KoqhpJK8Wu4VKIr9yIekbQIzJx11IYA9vjiJ38eJ2v1 x2NLnNDKrq2Q51l+iAy5MMbqmFWqljwZhPNfDW+ysybFMG1CtEnCgQPLqmbF9m9m 8M9uV/vfGKuD73GpmMR7MlHldySv+uiqJnFzyCce+QMzP7enCBitBDp0t52dRal7 TrTR7HGXIkVJ4I/73o3MBAfQrzmTsSIYmuVybArnaNzvrcT6aZTKH8hSPWRKVqx/ pcBP7Z+wLzHkJELWD0X9vgZJZJUj5qbMx6jq0NYYWY1lCrLTIRxXppS76/ZUzzIm qGS7FqUQM8u+x8rynnKNattFjWOdwXcFhcy3Io3Noc3kBDTgZf4fshBHWbO0XOqf BI3upFpAwQ4g4ep16o1k =CZnJ -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Grizzly-1 development milestone available (Keystone, Glance, Nova, Horizon, Quantum, Cinder)
Hi everyone, The first milestone of the Grizzly development cycle, grizzly-1 is now available. It contains all the new features that have been added since the Folsom pre-release Feature Freeze in September. You can see the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/grizzly/grizzly-1 https://launchpad.net/glance/grizzly/grizzly-1 https://launchpad.net/nova/grizzly/grizzly-1 https://launchpad.net/horizon/grizzly/grizzly-1 https://launchpad.net/quantum/grizzly/grizzly-1 https://launchpad.net/cinder/grizzly/grizzly-1 The Grizzly development cycle is now in full swing. The next milestone, grizzly-2, is scheduled for delivery on January 10th. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
Alan Pevec wrote: 2012/11/22 Lars Kellogg-Stedman l...@seas.harvard.edu: Any chance we can get it fixed in Essex, too? Or has this release been abandoned? I'm not clear on what the maintenance schedule looks like as the steamroller of progress moves forward. Current stable branch policy is documented in http://wiki.openstack.org/StableBranch tld;r openstack-stable-maint team actively backports fixes to stable/folsom branch. Separate openstack-diablo-maint and openstack-essex-maint teams exist for older branches, but they accept serious issues e.g. security fixes only. Note that diablo/essex-maint teams are 1-2 members only, so if you have resources I'm sure they'd welcome any help they can get. It's more a question of how disruptive the patch is vs. how critical the bug is. Given how annoying this bug is, it would be good to at least assess the disruption factor of a backport. Did we identify the bug number (or commit id) of the Folsom fix, so that we can open an Essex task for it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Nov 20)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The TC agreed on a general vision on the question of the future of Incubation and Core within the new OpenStack governance, based on a separation between trademark issues and what projects can actually grow within the OpenStack development umbrella. The approved direction is based on Mark McLoughlin and Anne Gentle proposals on the recent ML thread[1]. * We selected Mark McLoughlin and Anne Gentle to represent the TC in the joint committee that the Board of Directors will form to discuss that issue. Russell Bryant and Thierry Carrez will act as substitutes if needed. [1] http://lists.openstack.org/pipermail/openstack-dev/2012-November/thread.html#2387 See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-20-20.01.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Nov 13)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The following motion on 3rd-party APIs was approved: The previous aspirational statement that the PPB made in May 2012 about 3rd party APIs being implemented external to core stands. However, where a given project does not yet expose a stable, complete, performant interface for 3rd party APIs to build on, that project may choose to accept proposed new APIs in the interim if it sees fit. * Discussion continued on the Incubator/Core process update. The mailing-list thread at [1] shows signs of crystallization. Hopefully the TC will be able to agree at the next meeting on a direction and members to represent that direction on the future joint committee to be established with the Board of Directors. [1] http://lists.openstack.org/pipermail/openstack-dev/2012-November/thread.html#2387 * We had the initial discussion on distribution and Python version support policy. Discussion will continue on the mailing-list. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-13-20.02.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Minutes from the Technical Committee meeting (Nov 6)
The OpenStack Technical Committee (TC) met in #openstack-meeting at 20:00 UTC yesterday. Here is a quick summary of the outcome of this meeting: * The Heat project was granted Incubation status and will therefore be able to access additional OpenStack common resources, including tapping into CI, QA and Release management teams. * At the request of the Board of Directors, the TC discussed the future of the Incubation process. Given the variety of opinions and the breadth of the subject, it was decided to move that discussion to the openstack-dev mailing-list, so that the TC can better define its position before a future joint discussion with the Board of Directors. Once the Incubation process and what is OpenStack Core will be better defined, the TC will revisit the currently-incubated projects to check if they still fulfill the new definition, if any. See details and full logs at: http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-06-20.02.html More information on the Technical Committee at: http://wiki.openstack.org/Governance/TechnicalCommittee -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] summit web site down?
Doug Davis wrote: I was trying to find the name of the person who ran one of the sessions at the San Diego summit, but the session [1] doesn't list the name of the moderator (this would probably be a good thing to require for session description for the next summit). And so I then thought I might be able to find it via summit session proposal site [2] but that appears to be down. What is the best way to track down the names of the moderators of each session? yes we'll include them as a comment next time. To solve your issue, I started up the site again. FWIW it will be brought down in the future, but let's just wait for the Grizzly planning to be completed first :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] new mailing list for bare-metal provisioning
Mark T. Voelker wrote: Thus, I'd have missed those messages if I were only subscribed to the Quantum topic. It was my understanding that messages that don't include a proper topic end up being sent to everyone. So you can use topics to actively ignore stuff that has been marked [Nova], rather than only receive [baremetal] stuff. Personally I like to see everything so it doesn't much matter to me other than in how I set up my email filters, but I think perhaps this is one reason why we've had the discussion about more vs fewer mailing lists more than once. I personally prefer to receive everything and do filtering client-side too. Topics are just an additional option, I guess. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] new mailing list for bare-metal provisioning
Sam Stoelinga wrote: If mailing list gets separated, it would be good to have an aggregate mailing list we can subscribe to which has all nova related mailing lists. We really shouldn't go in that direction: the openstack-dev list is already an aggregator of topics, since we use mailman topics on it. I see a lot of drawbacks in having the ML separate. The only drawback I can think of in having the baremetal discussions on the main openstack-dev list is that some people might only want to receive baremetal stuff. Those (hopefully rare) people can use client-side filtering on the subject... or we also can setup a baremetal mailman topic so that you can directly filter using your ML preferences. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] new mailing list for bare-metal provisioning
David Kang wrote: Hello all, An openstack mailing list is created for the discussion of bare-metal provisioning. http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-baremetal Please join it if you are interested in participating the dicussion/collaboration of bare-metal provisioning. Hmm, any particular reason why you're not having those discussions on the development mailing-list instead ? That sounds a totally appropriate topic for that list... and the overlap between the two groups sounds pretty complete (B totally included in A). I would prefer if we didn't multiply the sublists for development subtopics and if we didn't force developers to subscribe to multiple lists just to keep informed on design discussions. That will avoid the subgroup coming up with a design that will be rejected by the larger group once it is submitted there. Why not use a subject prefix instead ? Like [baremetal] ? Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
