Fraser Tweedale: Wildcard SAN certificates in FreeIPA

Share Button

In an earlier post I discussed how to make a certificate profile for wildcard certificates in FreeIPA, where the wildcard name appeared in the Subject Common Name (CN) (but not the Subject Alternative Name (SAN) extension). Apart from the technical details that post also explained that wildcard certificates are deprecated, why they are deprecated, and therefore why I was not particularly interested in pursuing a way to get wildcard DNS names into the SAN extension.

But, as was portended long ago (more than 15 years, when RFC 2818 was published) DNS name assertions via the CN field are deprecated, and finally some client software removed CN name processing support. The Chrome browser is first off the rank, but it won’t be the last!

Unfortunately, programs that have typically used wildcard certificates (hosting services/platforms, PaaS, and sites with many subdomains) are mostly still using wildcard certificates, and FreeIPA still needs to support these programs. As much as I would like to say “just use Let’s Encrypt / ACME!”, it is not realistic for all of these programs to update in so short a time. Some may never be updated. So for now, wildcard DNS names in SAN is more than a “nice to have” – it is a requirement for a handful of valid use cases.

Configuration

Here is how to do it in FreeIPA. Most of the steps are the same as in the earlier post so I will not repeat them here. The only substantive difference is in the Dogtag profile configuration.

In the profile configuration, set the following directives (note that the key serverCertSet and the index 12 are indicative only; the index does not matter as long as it is different from the other profile policy components):

policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alternative Name Extension Default
policyset.serverCertSet.12.default.params.subjAltNameNumGNs=2
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=*.$request.req_subject_name.cn$
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_1=true
policyset.serverCertSet.12.default.params.subjAltExtType_1=DNSName
policyset.serverCertSet.12.default.params.subjAltExtPattern_1=$request.req_subject_name.cn$

Also be sure to add the index to the directive containing the list of profile policies:

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12

This configuration will cause two SAN DNSName values to be added to the certificate – one using the CN from the CSR, and the other using the CN from the CSR preceded by a wildcard label.

Finally, be aware that because the subjectAltNameExtDefaultImpl component adds the SAN extension to a certificate, it conflicts with the userExtensionDefault component when configured to copy the SAN extension from a CSR to the new certificate. This profile component will have a configuration like the following:

policyset.serverCertSet.11.constraint.class_id=noConstraintImpl
policyset.serverCertSet.11.constraint.name=No Constraint
policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl
policyset.serverCertSet.11.default.name=User Supplied Extension Default
policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17

Again the numerical index is indicative only, but the OID is not; 2.5.29.17 is the OID for the SAN extension. If your starting profile configuration contains the same directives, remove them from the configuration, and remove the index from the policy list too:

policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,12

Discussion

The profile containing the configuration outlined above will issue certificates with a wildcard DNS name in the SAN extension, alongside the DNS name from the CN. Mission accomplished; but note the following caveats.

This configuration cannot contain the userExtensionDefaultImpl component, which copies the SAN extension from the CSR to the final certificate if present in the CSR, because any CSR that contains a SAN extension would cause Dogtag to attempt to add a second SAN extension to the certificate (this is an error). It would be better if the conflicting profile components somehow “merged” the SAN values, but this is not their current behaviour.

Because we are not copying the SAN extension from the CSR, any SAN extension in the CSR get ignored by Dogtag – but not by FreeIPA; the FreeIPA CSR validation machinery always fully validates the subject alternative names it sees in a CSR, regardless of the Dogtag profile configuration.

If you work on software or services that currently use wildcard certificates please start planning to move away from this. CN validation was deprecated for a long time and is finally being phased out; wildcard certificates are also deprecated (RFC 6125) and they too may eventually be phased out. Look at services and technologies like Let’s Encrypt (a free, automated, publicly trusted CA) and ACME (the protocol that powers it) for acquiring all the certificates you need without administrator or operator intervention.

Powered by WPeMatico

Share Button

Alexander Todorov: What's the bug in this pseudo-code

Share Button

Rails Girls Vratsa sticker

This is one of the stickers for the second edition of Rails Girls Vratsa which
was held yesterday. Let’s explore some of the bug proposals submitted by the Bulgarian QA group:

  1. sad() == true is ugly
  2. sad() is not very nice, better make it if(isSad())
  3. use sadStop(), and even better – stopSad()
  4. there is an extra space character in beAwesome( )
  5. the last curly bracket needs to be on a new line

Lyudmil Latinov

My friend Lu describes what I would call style issues. The style he refers to
is mostly Java oriented, especially with naming things. In Ruby we would probably
go with sad? instead of isSad. Style is important and there are many tools
to help us with that this will not cause a functional problem! While I’m at it let me say
the curly brackets are not the problem either. They are not valid in Ruby this is
a pseudo-code and they also fall in the style category.

The next interesting proposal comes from Tsveta Krasteva. She examines the possibility
of sad() returning an object or nil instead of boolean value. Her first question was
will the if statement still work, and the answer is yes. In Ruby everything is an object
and every object can be compared to true and false. See
Alan Skorkin’s blog
post on the subject.

Then Tsveta says the answer is to use sad().stop() with the warning that it may return
nil. In this context the sad() method returns on object indicating that the person
is feeling sad. If the method returns nil then the person is feeling OK.

example by Tsveta

class Csad
  def stop()
    print("stopn");
  end
end

def sad()
  print("sadn");
  Csad.new();
end

def beAwesome()
  print("beAwesomen");
end

# notice == true was removed
if(sad())
  print("Yes, I am sadn");
  sad.stop();
  beAwesome( );
end

While this is coming closer to a functioning solution something about it is bugging me.
In the if statement the developer has typed more characters than required (== true).
This sounds to me unlikely but is possible with less experienced developers.
The other issue is that we are using an object (of class Csad) to represent an internal
state in the system under test. There is one method to return the state (sad()) and
another one to alter the state (Csad.stop()). The two methods don’t operate on
the same object! Not a very strong OOP design. On top of that we have to call the
method twice, first time in the if statement, the second time in the body of the
if statement, which may have unwanted side effects. It is best to assign the return
value to some variable instead.

IMO if we are to use this OOP approach the code should look something like:

class Person
  def sad?()
  end

  def stopBeingSad()
  end

  def beAwesome()
  end
end

p = Person.new
if p.sad?
    p.stopBeingSad
    p.beAwesome
end

Let me return back to assuming we don’t use classes here.
The first obvious mistake is the space in sad stop(); first spotted by Peter Sabev*.
His proposal, backed by others is to use sad.stop(). However they
didn’t use my hint asking what is the return value of sad() ?

If sad() returns boolean then we’ll get
undefined method 'stop' for true:TrueClass (NoMethodError)!
Same thing if sad() returns nil, although we skip the if block in this case.

In Ruby we are allowed to skip parentheses when calling a method, like I’ve shown
above. If we ignore this fact for a second, then sad?.stop() will mean execute the
method named stop() which is a member of the sad? variable, which is of type method!
Again, methods don’t have an attribute named stop!

The last two paragraphs are the semantic/functional mistake I see in this code. The only way
for it to work is to use an OOP variant which is further away from what the existing
clues give us.

Note: The variant sad? stop() is syntactically correct. This means call the function sad?
with parameter the result of calling the method stop(), which depending on the outer scope of this program may or may not
be correct (e.g. stop is defined, sad? accepts optional parameters, sad? maintains
global state).

Thanks for reading and happy testing!

Powered by WPeMatico

Share Button

Brian “bex” Exelbierd: Slice of Cake #11

Share Button

A slice of cake

In the last two weeks as FCAIC I:

  • Continued working on Flock, including organizing the budget so we could get some vendor approvals done. If you’re interested in tracking the progress, keep an eye on the flock-planning email list.
  • Attended LinuxCon Beijing – an event report is in the queue, I promise!
  • Attended the Education Day held by the Red Hat Beijing office. This exciting event will also get an event report but represented a great way to meet with potential members of the Fedora Community in Beijing.

A la Mode

  • Hahahaha with as much time as I spent in planes and stuck in airports I didn’t get to do anything for me.

Cake Around the World

I’ll be traveling some and hope you’ll ping me for coffee if you’re nearby.

  • Working from Gdansk, Poland from 3-4 July. Wanna get a coffee? We can pretend I am practicing my Polish!
  • LATAM Organizational FAD from 13-15 July in Cusco, Peru.
  • Flock on Cape Cod, Massachusetts, USA from 29 August – 1 September.

Powered by WPeMatico

Share Button

Fedora Magazine: Upcoming Fedora Atomic Host lifecycle changes

Share Button

The Fedora Project ships new Fedora Server and Workstation releases at roughly six-month intervals. It then maintains each release for around thirteen months. So Fedora N is supported by the community until one month after the release of Fedora N+2. Since the first Fedora Atomic Host shipped, as part of Fedora 21, the project has maintained separate ostree repositories for both active Fedora releases. For instance, there are currently trees available for Fedora Atomic 25 and Fedora Atomic 24.

Fedora Atomic sets out to be a particularly fast-moving branch of Fedora. It provides releases every two weeks and updates to key Atomic Host components such as Docker and Kubernetes. The release moves more quickly than one might expect from the other releases of Fedora.

Due in part to this faster pace, the Fedora Atomic Working Group has always focused its testing and integration efforts most directly on the latest stable release. The group encourages users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a best effort basis. This means the ostree is updated, but there is no organized testing of older releases.

Upcoming changes

This will change with either the Fedora 26 to 27 or the 27 to 28 upgrade cycle (depending on readiness). The Fedora Atomic Working Group will then collapse Fedora Atomic into a single version. That release will track the latest stable Fedora branch. When a new stable version of Fedora is released, Fedora Atomic users will automatically shift to the new version when they install updates.

Traditional OS upgrades can be disruptive and error-prone. Due to the image-based technologies that Atomic Hosts use for system components (rpm-ostree) and for applications (Linux containers), upgrading an Atomic Host between major releases is like installing updates within a single release. In both scenarios, the system updates are applied by running an rpm-ostree command and rebooting. The release provides rollback to the previous state available in case something goes wrong. Applications running in containers are unaffected by the host upgrade or update.

If you’d like to get involved in the Fedora Atomic Working Group, come talk to us in IRC in #fedora-cloud or #atomic on Freenode, or join the Atomic WG on Pagure.

Powered by WPeMatico

Share Button

Upcoming Fedora Atomic Host lifecycle changes

Share Button

The Fedora Project ships new Fedora Server and Workstation releases at roughly six-month intervals. It then maintains each release for around thirteen months. So Fedora N is supported by the community until one month after the release of Fedora N+2. Since the first Fedora Atomic Host shipped, as part of Fedora 21, the project has maintained separate ostree repositories for both active Fedora releases. For instance, there are currently trees available for Fedora Atomic 25 and Fedora Atomic 24.

Fedora Atomic sets out to be a particularly fast-moving branch of Fedora. It provides releases every two weeks and updates to key Atomic Host components such as Docker and Kubernetes. The release moves more quickly than one might expect from the other releases of Fedora.

Due in part to this faster pace, the Fedora Atomic Working Group has always focused its testing and integration efforts most directly on the latest stable release. The group encourages users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a best effort basis. This means the ostree is updated, but there is no organized testing of older releases.

Upcoming changes

This will change with either the Fedora 26 to 27 or the 27 to 28 upgrade cycle (depending on readiness). The Fedora Atomic Working Group will then collapse Fedora Atomic into a single version. That release will track the latest stable Fedora branch. When a new stable version of Fedora is released, Fedora Atomic users will automatically shift to the new version when they install updates.

Traditional OS upgrades can be disruptive and error-prone. Due to the image-based technologies that Atomic Hosts use for system components (rpm-ostree) and for applications (Linux containers), upgrading an Atomic Host between major releases is like installing updates within a single release. In both scenarios, the system updates are applied by running an rpm-ostree command and rebooting. The release provides rollback to the previous state available in case something goes wrong. Applications running in containers are unaffected by the host upgrade or update.

If you’d like to get involved in the Fedora Atomic Working Group, come talk to us in IRC in #fedora-cloud or #atomic on Freenode, or join the Atomic WG on Pagure.

Powered by WPeMatico

Share Button

Julita Inca Chiroque: Stuck in the Challenge

Share Button

My Sunday days are reserved for the GNOME Peru Challenge 2017-1 and one key action to  success is to get an application running, to fix a bug. In this matter, jhbuild and GNOME Builder are the way to achieve it.

Unfortunately, when we are trying to clone an app, libraries missing are the problem. These are some screenshots of the job of our group so far.

Felipe Moreno with Test Builder on Fedora   Martin Vuelta with Polari on ArchiLinux

Randy Real with Polari on Fedora

Ronaldo Cabezas with Gedit on Fedora

Julita Inca with Cheese on Fedora

I hope we can overcome this situation to post in a near future “A successful way to clone apps with GNOMe Builder” 😉

  • Thanks to Randy Real for arranging a lab at UIGV today, and for his support.
  • This journey, we had the honor to count with a developer from Brasil called Thiago!

Filed under: FEDORA, GNOME, τεχνολογια :: Technology Tagged: clone problem, clonning apps, fedora, Fedora + GNOME community, GNOME, gnome 3, GNOME bug, GNOME Builder, GNOME Peru Challenge, GNOME Peru Challenge 2017, Julita Inca, Julita Inca Chiroque

Powered by WPeMatico

Share Button

Josh Bressers: When in doubt, blame open source

Share Button


If you’ve not read my previous post on thought leadership, go do that now, this one builds on it. The thing that really kicked off my thinking on these matters was this article:

Security liability is coming for software: Is your engineering team ready?

The whole article is pretty silly, but the bit about liability and open source is the real treat. There’s some sort of special consideration when you use open source apparently, we’ll get back to that. Right now there is basically no liability of any sort when you use software. I doubt there will be anytime soon. Liability laws are tricky, but the lawyers I’ve spoken with have been clear that software isn’t currently covered in most instances. The whole article is basically nonsense from that respect. The people they interview set the stage for liability and responsibility then seem to discuss how open source should be treated special in this context.

Nothing is special, open source is no better or worse than closed source software. If you build something why would open source need more responsibility than closed source? It doesn’t of course, it’s just an easy target to pick on. The real story is we don’t know how to deal with this problem. Open source is an easy boogeyman. It’s getting picked on because we don’t know where else to point the finger.

The real problem is we don’t know how to secure our software in an acceptable manner. Trying to talk about liability and responsibility is fine, nobody is going to worry about security until they have to. Using open source as a discussion point in this conversation clouds it though. We now get to shift the conversation from how do we improve security, to blaming something else for our problems. Open source is one of the tools we use to build our software. It might be the most powerful tool we’ve ever had. Tools are never the problem in a broken system even though they get blamed on a regular basis.

The conversation we must have revolves around incentives. There is no incentive to build secure software. Blaming open source or talking about responsibility are just attempts to skirt the real issue. We have to fix our incentives. Liability could be an incentive, regulation can be an incentive. User demand can be an incentive as well. Today the security quality of software doesn’t seem to matter.

I’d like to end this saying we should make an effort to have more honest discussions about security incentives, but I don’t think that will happen. As I mention in my previous blog post, our problem is a lack of leadership. Even if we fix security incentives, I don’t see things getting much better under current leadership.

Powered by WPeMatico

Share Button

Julita Inca Chiroque: First Round Talks of Fedora + GNOME at UPN

Share Button

Today our local group has traveled many miles to the north of Lima to present our lately work by using Fedora and GNOME as users and developers. Thanks to the organizers of the IT Forum to invite us and support our job as Linux volunteers and very nice potential contributors to GNOME and Fedora and the group we have formed.I has started with what Linux is, who have created it, why do they created it, why it is important, what Fedora is, what GNOME is, how did I get involved in GNOME and Fedora, how anyone can be involved,  about the awesome GNOME and Fedora community

Then Solanch Ccasas did share her experiences in the workshops she had helped me in the last year as well as her experiences in the GNOME Peru Challenge. Great job Solanch! 🙂Toto is another fantastic potential contributor to both projects and I trust him the general coordination of the GNOME Peru Challenge. Thank you so much Toto for all your effort!Followed by Toto, it was Leyla! Our outstanding designer and also python trained student in the GNOME Peru Challenge. She organized many FLOSS events and she is so lovely! 😀The hardworking Martin was also there supporting us! He is an experiment developer and talent IT people, he is physics and also smart and funny person. Say hi to Martin Vuelta! 😉Alex is another autodidact and inspired guy who is always helping us in this effort. He did a talk regarded on the terminal and commands that help developers in their daily 😀Felipe Moreno is another very well skilled student that explain us GTK and his experiences with Go and IT related technologies with GNOME y Fedora. Grow up in FLOSS Felipe! 🙂Sheyla is also a student of mechatronic at UTP. She is a programmers and designer, she has been involved in the GNOME Peru Challenge lately and I hope she will fix a bug soon!Last but not least! Mario Antizana was showing his work with Mechatronics and his experiences with KIA Motors and the Fedora project he has proposed and won! Awesome!The fee for the event had not charge, it was for free and we definitely prize our attendances

Screen Shot 2017-06-24 at 11.17.33 PM

Thanks to GOD first! for having the support of these talent and good people to build a Linux community that exert me to be a better leader and person for the sake of our group!Every experience we have as a group is a new satisfactory adventure, we enjoy this way… despite of ignorance, ridiculous and opposition! Thanks again guys! More pics as follow:Thanks again to the UPN (Private University of North) for everything!

Filed under: FEDORA, GNOME, τεχνολογια :: Technology Tagged: community, fedora, Fedora + GNOME community, FLOSS, FLOSS community, GNOME, GNOME 3.22, GNOME Peru Challenge, GNOME Peru Challenge 2017, Julita Inca, Julita Inca Chiroque, Lima, linux, Perú, UPN

Powered by WPeMatico

Share Button

Mo Morsi: RetroFlix / PI Switch Followup

Share Button

I’ve been trying to dedicate some cycles to wrapping up the Raspberry PI entertainment center project mentioned a while back. I decided to abandon the PI Switch idea as the original controller which was purchased for it just did not work properly (or should I say only worked sporadically/intermitantly). It being a cheap device bought online, it wasn’t worth the effort to debug (funny enough I can’t find the device on Amazon anymore, perhaps other people were having issues…).

Not being able to find another suitable gamepad to use as the basis for a snap together portable device, I bought a Rii wireless controller (which works great out of the box!) and dropped the project (also partly due to lack of personal interest). But the previously designed wall mount works great, and after a bit of work the PI now functions as a seamless as a media center.

Unfortunately to get it there, a few workarounds were needed. These are listed below (in no particular order).

  • To start off, increase your GPU memory. This we be needed to run games with any reasonable performance. This can be accomplished through the Raspberry PI configuration interface.

    Rpi setup1
    Rpi setup2

    Here you can also overclock your PI if your model supports it (v3.0 does not as evident w/ the screenshot, though there are workarounds

  • If you are having trouble w/ the PI output resolution being too large / small for your tv, try adjusting the aspect ratio on your set. Previously mine was set to “theater mode”, cutting off the edges of the device output. Resetting it to normal resolved the issue.

    Rpi setup3
    Rpi setup5
    Rpi setup4

  • To get the Playstation SixAxis controller working via bluetooth required a few steps.

    • Unplug your playstation (since it will boot by default when the controller is activated)
    • On the PI, run
              sudo bluetoothctl
      
    • Start the controller and watch for a new devices in the bluetoothctl output. Make note of the device id
    • Still in the bluetoothctl command prompt, run
              trust [deviceid]
      
    • In the Raspberry PI bluetooth menu, click ‘make discoverable’ (this can also be accomplished via the bluetoothctl command prompt with the discoverable on command)

      Rpi setup6

    • Finally restart the controller and it should autoconnect!
  • To install recent versions of Ruby you will need to install and setup rbenv. The current version in the RPI repos is too old to be of use (of interest for RetroFlix, see below)
  • Using mednafen requires some config changes, notabley to disable opengl output and enable SDL. Specifically change the following line from
          video.driver opengl
    

    To

          video.driver sdl
    

    Unfortunately after alot of effort, I was not able to get mupen64 working (while most games start as confirmed by audio cues, all have black / blank screens)… so no N64 games on the PI for now 🙁

  • But who needs N64 when you have Nethack! (the most recent version of which works flawlessly). In addition to the small tweaks needed to compile the latest version on Linux, inorder to get the awesome Nevanda tileset working, update include/config.h to enable XPM graphics:
        -/* # define USE_XPM */ /* Disable if you do not have the XPM library */
        +#define USE_XPM  /* Disable if you do not have the XPM library */
    

    Once installed, edit your nh/install/games/lib/nethackdir/NetHack.ad config file (in ~ if you installed nethack there), to reference the newtileset:

        -NetHack.tile_file: x11tiles
        +NetHack.tile_file: /home/pi/Downloads/Nevanda.xpm
    

Finally RetroFlix received some tweaking & love. Most changes were visual optimizations and eye candy (including some nice retro fonts and colors), though a workers were also added so the actual downloads could be performed without blocking the UI. Overall it’s simple and works great, a perfect portal to work on those high scores!

That’s all for now, look for some more updates on the ReFS front in the near future!

Powered by WPeMatico

Share Button

Christian Dersch: Improving QtWebKit security for Fedora

Share Button


The Qt port of the WebKit engine was unmaintained for years, until Konstantin Tokarev (also known as annulen) decided to pick it up about ten months ago. Within the last months he did an impressive job on getting QtWebKit up to date again, some days ago he released the second alpha of QtWebKit 5.212.0. As the current state of QtWebkit is really bad in Fedora, we always shipped the latest one from Qt upstream, but they did not do any backports of security fixes from upstream WebKit anymore, the KDE SIG now decided to move to the new community QtWebKit. Qt itself only supports the QtWebEngine based on Chromium, which itself has some issues (hard to maintain as we have to remove codec stuff, always some Chromium releases behind) , but more important: Many applications have not been ported and still use QtWebKit. With Konstantins work on QtWebKit it is possible to use them without all these unfixed security issues again. There are also some reasons to use QtWebKit instead of QtWebEngine, checkout the QtWebKit Wiki.

Within the last two weeks I worked on packaging the new QtWebKit and testing it with several browsers and KDE components to ensure that we do not break the world. So far it looks like new QtWebKit is what it is promised to be: a drop-in replacement for the old one, even without the need to recompile anything. For now our plan to get it in Fedora:

  • Provide a copr for wider testing, already done, checkout https://copr.fedorainfracloud.org/coprs/lupinix/qtwebkit-annulen/
  • Import into Rawhide (done)
  • Update all qt5-qtwebkit packages for Fedora 24+ when some more testing is done, current plan is a 0day update for Fedora 26 (we will not get it in before final freeze) and updates for Fedora 24 and 25 at the same time
Note that I’m talking about the Qt5 version of QtWebKit. There is no upstream support for Qt4 anymore, but it is still in Fedoras repositories. So Qt4 QtWebKit is still without any fixes, I guess we should retire it at some point, in the same way our WebKitGTK+ friends already did.

Powered by WPeMatico

Share Button