Archive

Archive for the ‘FAD’ Category

Security Team Post-FAD Notes

2016-03-16 Leave a comment

On 11 March, some of the Security Team met in Washington, D.C. for a day-long FAD where we discussed several issues.  Zach Oglesby released his notes from the meeting and I’ll be using those to describe my take-away from the meeting.

Security Updates

Right now Fedora has a couple of problems with getting security fixes onto people’s systems quickly.  The first has to do with embargoes.  Because Fedora isn’t part of the trusted network, we don’t get advance notification of vulnerabilities before their embargo is lifted.  This means that when we are notified of an urgent security vulnerability the public also has the information and we’re left scrambling to find the fix (patch, new version, etc) and ship it.  Some other flavors of Linux will have had advance notice and will have these patches or new versions packaged up and ready to ship with the embargo is lifted.

The other problem deals with the Fedora Mirror network.  Because there are many mirrors it could take many hours or days(?) to get a security update out to all Fedora users.  This has to do with the mechanisms involved for keeping the Mirror system efficient; not necessarily fast.  We discussed potential solutions for this problem as well.

Working with embargoes

Our solution to working with embargoes is to create a trusted team, with the appropriate tools, to deal with these issues so we can get a head start on urgent security vulnerabilities.

20160311_104450Right now the infrastructure isn’t in place to be able to handle embargoed vulnerabilities.  Red Hat’s Bugzilla instance is currently designed to hold embargoed information, which is good and we definitely want to leverage that resource, but we need our build system and perhaps even Bodhi to be able to support private builds.  The idea is to have the packages built and ready to ship before the embargo expires.  When the embargo is lifted we would just need to push the big red button and the packages would ship.

It would also be hoped that the fix would have gone through QA before the end of the embargoed period so that we’re fairly sure that we’re not breaking anything (other than the vulnerability) in the process.  For this part, we’re going to need trusted individuals to work on these issues.

Oh, and make no mistake, we aren’t trying to hide information forever.  To maintain transparency that Fedora has been build on all of our tools we use to handle embargoed information should be able to make that information public at the end of the embargo.  Bugzilla tickets would be opened up to the public and builds should be made available as well.

Trust

20160311_121055Trust is a difficult thing to define.  How do you establish trust and how do you penalize a break in that trust?  Simply put, we need a way to do both before we start handling sensitive information.  We might be able to show that we have the systems and the procedures for handling this information but the first time there’s a leak and it comes from inside Fedora it’s quite likely we will lose access to this information and be back to where we are today.

We will be working with legal and Fedora management (FPL, FESCo, and Release Engineering) to devise a plan and determine the best way to involve package maintainers, proven packagers, and QA.

Faster access to Security Fixes

Waiting hours or days for urgent security fixes to become available on mirrors really isn’t acceptable.  Recent critical vulnerabilities have seen exploits in the wild shortly after the vulnerability being made public.  We need to be able to get fixes out to users faster.

Debian uses separate servers to deliver security fixes until those fixes have propagated out to their normal mirrors.  This could work, especially with diff packages being used which are usually much smaller than the full package, but would increase the infrastructure needed to support disseminating packages.

There may also be a way to tweak our existing infrastructure to improve the time it takes to push these urgent packages out.  Either way, the Security Team will be working with Release Engineering to help figure out a solution.

Training

Another big topic we covered is training.  Many people turn to the Security Team to learn.  From a team point of view, we want to make sure our members have a common base of knowledge from which to work.  We decided to launch Apprentice and Journey level certifications to will provide this base of knowledge.

Apprenticeship

20160311_143800.jpgWe worked through what we would want to see in a new member and created the Security Team Apprenticeship.  While not fully complete, we hope to have it ready in the coming months.

We also talked about mentors and what it means to be a mentor.

20160311_145049.jpgWe didn’t put down many hard and fast rules and that’s okay.  We want people to be active and participate.  Hopefully the mentors won’t have a heavy lift and neither will the mentees.

Obligatory GPG Key Signing

Of course, a security FAD can’t end without the obligatory GPG key signing.  This was completed with two new members of the team.

The End

So what I’ve documented represents a day of work.  Thanks to all that participated, even if you only had a chance to pop in, virtually, and lend your opinions or support.  Hopefully we can do this again in a few months and work on new tasks.

Fedora Security Team FAD 2016

2016-03-02 Leave a comment

In a couple of weeks (March 11th) the Fedora Security Team will be meeting in Washington, D.C. to hack on training, security fixes, and other issues.  All Fedora contributors are welcome to stop by if you’re in the area.

All the information is available on the Security Team FAD 2016 wiki page.  Please go there and RSVP!

Fedora Docs’ FAD 2014

2014-03-23 Leave a comment

It’s good to get a team together, face-to-face, that usually only meets virtually via IRC on occasion.  The Fedora Docs Project team recently had such an opportunity when they met in the Red Hat offices in Raleigh and Brno.  Linked by a video teleconference, the two groups converged to discuss new work-flows for Publican 4, hacking on some guides, discussing management issues, and working to get the new Docs website built and configured.  Here are some of the highlights of the event:

Work-flow update for Publican 4

The release of Fedora 20 also saw the release of Publican 4.  Publican 4 isn’t quite backwards compatible with the Publican 2 we were using so an update to our work-flow was necessary.  We’ve also made it to a point in our work where using the old web.git repo for publishing just isn’t working any longer.  The new way of publishing involves using Koji to build our documents in RPMs and place them safely into a repository where they can be grabbed by our backend server and be published to the world.  This change not only represents new commands but also a different mindset to publishing.  The new procedures were documented and tested so we’ll be able to start utilizing these as soon as our backend server gets fixed.

Guides hacked upon

You know those guides that seem to languish?  Yeah, I’ve got a few of those.  I did spend some time working on a few guides that will hopefully go live for Fedora 20 or 21.

Accessibility Guide

The Accessibility Guide has really taken a backseat in recent releases.  I’m not sure much has changed for many users but it’s good to keep the document current for any new users that may require a little assistance in making their computer work for them.  I was able to take a lot of stuff out of the guide, mostly GNOME packages that are no longer in Fedora and add a couple of packages I found for KDE.  I’m hoping I can do a better review of what’s available in Fedora before Fedora 21 comes around.

Amateur Radio Guide

I finally got around to adding CQRLOG to the guide.  I really love CQRLOG as a logging program so I’m happy to share some of that information with other amateur radio operators that come to Fedora looking for a FOSS solution for their radio activities.  John made a few additions as well so I suspect the next release will have some added goodness that people should find helpful.

Documentation Guide

This is where I spent most of my time working.  The style guide was moved from the wiki into the guide and other useful information was added as well.

Jargon Guide

This guide has never really seen the light of day.  This is due to the fact that translations of this guide would be nearly useless as they wouldn’t be in any particular order.  Publican 4 fixes this long-standing bug and so I, once again, have hope to publish this book.

Security Guide

Yeah, there’s always some hacking on the security guide when I’m around.  This time there was some testing of the new Yubikey Neo and getting them to do tricks inside Fedora.

New backend server

Jared worked very diligently to create a new backend server.  Unfortunately the documentation was lacking and so we weren’t able to complete the build.  Work continues on this effort.

Videos of the FAD

Because most of the event took place over our video chat you can watch the videos from the meeting: Friday, Saturday, and Sunday.

Fedora Docs QA Process

2011-06-11 Leave a comment
Notes from SELF 2011

At the SouthEast LinuxFest (SELF) a few Docs folks grabbed a room and started discussing some processes for QA with the Docs Project.

A few months ago the idea was had to have a QA team that would review the text and DocBook code to make sure what we are saying is correct and has consistent XML tags.  Several members stepped forward work this project but the process never really got off the ground and the organization never came together.

At the SELF FAD we tried to make the process easy and yet functional.  Basically we created two processes: new text and bug fixes.

The new text process involves creating the new guide/article, committing it to a repo, opening up a BZ ticket, having someone from Docs QA go through the guide making sure that the processes and procedures are correct and that the DocBook XML tags are correct and consistent, then branching the repo and publishing.  Similarly, bug fixes have their patches reviewed prior to be committed to the branch for publishing.

Not only does this give us the opportunity to “clean up” our documents before they hit the streets, this will also give us an opportunity to engage our new contributors that may not be experienced with writing in DocBook XML.

This is by no means the new “policy” but rather a proposal.  Discussion will be over on the Docs List.  I’m hoping this proposal is a win-win situation for Docs!

Categories: FAD, Fedora Docs QA

SELF Day Three – Drupal Camp and Fedora Activity Day

2010-06-13 Leave a comment

Day three started off with a bang.  I met Paul at the “Beginner’s class for Drupal” during the Drupal Camp.  During that class we were given lots of good information on Drupal including how to install and set up Drupal in less than five minutes.

Several Fedorians then gathered at the local Krispy Kreme to discuss the upcoming Fedora Activity Day (FAD) that was to begin at 1PM.  Paul and Max started putting together their plan to debunk myths within Fedora.  Ian was tasked with explaining how to becoming a contributor and how to utilize the wiki.  With the best laid plans we returned to the conference center with a plan to dazzle all that attended the FAD.

The FAD began promptly at 1PM with thirty to forty participants.  Paul answered lots of questions including those regarding RPM dependency hell, that it’s difficult to get packages into Fedora, and how you don’t have to be a programmer to be a contributor.

Max took over for Paul and we were soon into becoming a contributor.  Ian walked everyone through the process of getting a FAS account and signing the CLA.  One gentleman in the crowd signed up immediately!

After going over the process we dove into filing bugs using Bugzilla.  Using an actual problem found we created the bug, gathering as much information as possible, and submitted it upstream to the Kernel Opps site.

After working through the bug we had more of a round-table discussion on Fedora.  Unfortunately it was past 4PM at this point and we needed to get on the road.  I really appreciate everyone who came out to the FAD and participated!  See you next year!

Creative Commons License
Sparks’ Fedora Project Journal by Eric H Christensen is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

FAD (Hackfest) @ SELF – In progress

2010-06-11 Leave a comment

This morning several Fedorians met to discuss Insight.  Now we are getting ready to hack on the wiki in hopes of making it easier to find the information you seek.

The Docs Project wiki pages will also get some work in hopes of documenting how we do documentation and to clean up some of our processes.  More on this later…

Creative Commons License
Sparks’ Fedora Project Journal by Eric H Christensen is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Good Morning SELF

2010-06-11 Leave a comment

Well, SELF hasn’t actually started but I slept as long as I could and I’m up!  Where is everyone?

Hackfest at 1P.  Until then Joat and I will be setting up NORAD in our hotel room.  Voice comms on 146.55MHz and data comms on 144.39MHz.

Creative Commons License
Sparks’ Fedora Project Journal by Eric H Christensen is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Follow

Get every new post delivered to your Inbox.

Join 287 other followers