Re: [openstack-dev] [OSSG] Best tool for simple security gate

[Travis McPeak]

Sorry for quoting the entire previous digest, twas a noob mistake.

Thanks,
  -Travis




On 6/19/14, 11:22 AM, openstack-dev-requ...@lists.openstack.org
openstack-dev-requ...@lists.openstack.org wrote:

Message: 33
Date: Thu, 19 Jun 2014 11:21:24 -0700
From: Travis McPeak travis_mcp...@symantec.com
To: openstack-dev@lists.openstack.org
   openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OSSG] Best tool for simple security gate
   checks
Message-ID: cfc8760c.40eb%travis_mcp...@symantec.com
Content-Type: text/plain; charset=Windows-1252

Hi all,

In the OpenStack Security Group (OSSG) we?ve been kicking around the idea
of getting some simple non-blocking security-related gate tests going.
These tests would be designed to be simple and automated checks for
low-hanging fruit such as the use of ?Shell=True?.  The main goal is to
have these be as noiseless as possible (a low rate of false positives).
The hope is that if these are useful and unobtrusive enough, when they
actually do fail, people will take note.

We will start off small, with maybe one simple gate test, and expand later
if it proves to be useful.  We plan to test heavily internally, and then
start requesting integration into projects later.

My question is: what is the best tool for the job?  I have heard Pylint
and Hacking mentioned.  Are there any others?

Thanks,
  -Travis


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] IRC Mishaps

[Travis McPeak]

How about the crowd favorite of accidentally submitting your password in
chat instead of where you were trying to?

At least people can help you evaluate your password strength :)

On Wed, Feb 8, 2017, 12:38 PM Kendall Nelson  wrote:

> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into our
> project channels, misusing '/' commands, etc. But have any of you actually
> done it?
>
> If any of you cores, ptls or other upstanding members of our wonderful
> community have had one of these embarrassing experiences please reply! I am
> writing an article for the SuperUser trying to make us all seem a little
> more human to people new to the community and new to using IRC. It can be
> scary asking questions to such a large group of smart people and its even
> more off putting when we make mistakes in front of them.
>
> So please share your stories!
>
> -Kendall Nelson (diablo_rojo)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] New blog post - "Secure Development in Python"

[Travis McPeak]

For those that aren't aware the OSSP maintains a blog:
http://openstack-security.github.io/.

I published a new post today about resources created by the OSSP to help
developers write secure Python code.  You can view it here:
http://openstack-security.github.io/organization/2016/09/26/python-secure-development.html
.

We hope you find it useful, and as always, if you have questions please
send them to the Dev ML (with the [Security] tag) or visit us on
#openstack-security on IRC.

-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Travis Mcpeak]

Ouch.  I'd be among the first to admit I don't keep up with dev ML
as I should.  Missing the PTL elections is certainly embarrassing
for us and it shouldn't be the community's job to baby-sit us and
make sure we're meeting our OpenStack deadlines.

That being said, relegating us to a working group seems like a
knee-jerk and drastic consequence to levy against a project as
vibrant as ours.

In a previous response Rob has highlighted many of our recent
accomplishments, so I won't revisit that here. 

What I do want to mention is the work Rob himself has done to
coordinate and secure funding for our fifth consecutive mid-cycle 
(and each prior to that).  He has worked consistently to build support 
for our initiatives, both within and outside of OpenStack. 

Since assuming the PTL role none of our active members have been
inclined to run against him.

So yes, he's dropped the ball on reading the ML (I have too).  If
allowed to keep our project status we'll ensure that these mistakes
don't happen in the future.

Taking away our project status because "we act like a working group"
is an unfair categorization and, in my opinion, a severe reaction to a
relatively minor infraction.

-Travis McPeak



From:   openstack-dev-requ...@lists.openstack.org
To: openstack-dev@lists.openstack.org
Date:   09/21/2016 05:04 AM
Subject:OpenStack-dev Digest, Vol 53, Issue 51



Send OpenStack-dev mailing list submissions to
 openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
 openstack-dev-requ...@lists.openstack.org

You can reach the person managing the list at
 openstack-dev-ow...@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."


Today's Topics:

   1. Re: [cinder][sahara] LVM vs BDD drivers performance tests
  results (Micha? Dulko)
   2.  [manila] Enable IPv6 in Manila Ocata (jun zhong)
   3. [vitrage] Barcelona design sessions (Afek, Ifat (Nokia - IL))
   4.  [Kuryr] Kuryr IPVlan Code PoC (Daly, Louise M)
   5. Re: [Neutron] Adding ihrachys to the neutron-drivers team
  (Rossella Sblendido)
   6. Re: [tripleo] Setting kernel args to overcloud nodes
  (Saravanan KR)
   7. Re: [tripleo] [puppet] Preparing TripleO agenda for Barcelona
  - action needed (Giulio Fidente)
   8. [security] [salt] Removal of Security and OpenStackSalt
  project teams from the Big Tent (Thierry Carrez)
   9. Re: [tc]a chance to meet all TCs for Tricircle big-tent
  application in Barcelona summit? (Mike Perez)
  10. Re: [stackalytics] [deb] [packaging] OpenStack contribution
  stats skewed by deb-* projects (Thierry Carrez)
  11. [ptl] code churn and questionable changes (Amrith Kumar)


--

Message: 1
Date: Wed, 21 Sep 2016 09:57:43 +0200
From: Micha? Dulko <michal.du...@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)"
 <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers
 performance tests results
Message-ID: <ca9f10ad-51e4-274c-95bd-247719c89...@intel.com>
Content-Type: text/plain; charset=UTF-8

On 09/20/2016 05:48 PM, John Griffith wrote:
> On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas
> <duncan.tho...@gmail.com <mailto:duncan.tho...@gmail.com>> wrote:
>
> On 20 September 2016 at 16:24, Nikita Konovalov
> <nkonova...@mirantis.com <mailto:nkonova...@mirantis.com>> wrote:
>
> Hi,
>
> From Sahara (and Hadoop workload in general) use-case the
> reason we used BDD was a complete absence of any overhead on
> compute resources utilization. 
>
> The results show that the LVM+Local target perform pretty
> close to BDD in synthetic tests. It's a good sign for LVM. It
> actually shows that most of the storage virtualization
> overhead is not caused by LVM partitions and drivers
> themselves but rather by the iSCSI daemons.
>
> So I would still like to have the ability to attach partitions
> locally bypassing the iSCSI to guarantee 2 things:
> * Make sure that lio processes do not compete for CPU and RAM
> with VMs running on the same host.
> * Make sure that CPU intensive VMs (or whatever else is
> running nearby) are not blocking the storage.
>
>
> So these are, unless we see the effects via benchmarks, completely
> meaningless requirements. Ivan's initial benchmarks suggest
> that LVM+LIO is pretty much close enoug

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Travis McPeak]

"So all this said, there are individuals interested in the PTL role to
ensure project teams have someone handling the logistics and coordination.
My issue however was that I was not yet eligible to be a candidate which
I'll remedy moving forward.

I'm still interested in serving as a PTL for a project that needs one. I
personally believe that in the case of Security, there needs to be a
dedicated team due to the nature and impact of security breaches that
directly influence the perception of OpenStack as a viable cloud solution
for enterprises looking (or re-looking) at it for the first time."

@Adam we'd certainly appreciate your help staying on top of

required activities, email, etc.  Surely a PTL should be

somebody who has at least been involved in the project?

-- 
-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

[Travis McPeak]

"My answer would be -that- is the most ideal scenario. I care about
OpenStack and ensuring quality projects have adequate representation so I
checked to see which ones didn't have anyone defined for leadership and
picked one to step in and help, assuming no one was able to fill that role
for that specific cycle."

Ahh gotcha.  Thanks Adam.  We definitely welcome your advice and help
with socializing our activities and becoming more integrated with the
community.  I think Ian (sigmavirus) is similarly interested.  I look
forward to working with both of you.

-- 
-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] XML Attacks and DefusedXML on Global Requirements

[Travis McPeak]

There are several attacks (https://pypi.python.org/pypi/defusedxml#id3)
that can be performed when XML is parsed from untrusted input.  DefusedXML
offers safe alternatives to XML parsing libraries but is not currently part
of global requirements.

I propose adding DefusedXML to global requirements so that projects have an
option for safe XML parsing.  Does anybody have any thoughts or objections?

Thanks,
-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Security] XML Attacks and DefusedXML on Global Requirements

[Travis McPeak]

There is a private security bug about it right now too.  No, not all XML
libraries are immune now.

On Tue, Sep 27, 2016 at 11:36 AM, Dave Walker <em...@daviey.com> wrote:

>
>
> On 27 September 2016 at 19:19, Sean Dague <s...@dague.net> wrote:
>
>> On 09/27/2016 01:24 PM, Travis McPeak wrote:
>> > There are several attacks (https://pypi.python.org/pypi/defusedxml#id3)
>> > that can be performed when XML is parsed from untrusted input.
>> > DefusedXML offers safe alternatives to XML parsing libraries but is not
>> > currently part of global requirements.
>> >
>> > I propose adding DefusedXML to global requirements so that projects have
>> > an option for safe XML parsing.  Does anybody have any thoughts or
>> > objections?
>>
>> Out of curiosity, are there specific areas of concern in existing
>> projects here? Most projects have dropped XML API support.
>>
>>
> Outbound XML datasources which are parsed still used with at least nova
> vmware support and multiple cinder drivers.
>
> openstack/ec2-api is still providing an xml api service?
>
> --
> Kind Regards,
> Dave Walker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Travis McPeak]

+1 for Ian.  He has great security knowledge and will be an awesome asset
for any security team.

On Tue, Oct 18, 2016, 3:24 PM Brian Rosmaita 
wrote:

> Hello everyone,
>
> First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
> service as members of the Glance core security contacts team.
> Unfortunately, due to other commitments, they don't have time to continue
> on coresec.
>
> Thus, the main point of this email is to propose Ian Cordasco and Erno
> Kuvaja as new members of the Glance coresec team.  They've both been
> Glance cores for several cycles, have a broad knowledge of the software
> and team, contribute high-quality reviews, and are conversant with good
> security practices.
>
> Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
> team at 5 members.
>
> Please cast your vote with +1, 0, or -1, or you can reply back to me.
>
> Please reply before 23:59 UTC on Wednesday, October 26, 2016.
>
> Thank you,
> brian
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev