Fixing our meeting time
by Paul W. Frields
A couple issues have come up with our current meeting time of 9:00am
US-Eastern, 1300 UTC on Monday:
(1) In several (two of the last three, most recently) fortnightly WG
meetings, we've had trouble reaching quorum.
(2) I have a to facilitate a meeting directly after this one which
requires my attention about 5-10 minutes before the hour, meaning it's
difficult to stay in our meeting at the precise point where we need to
wrap up.
I suspect this time is also not conducive for a couple other
US-Eastern folks who (unlike me) are traveling to an office around
this time on Monday mornings, but I don't want to speak for anyone
else.
When we did our meeting time check in April, the matrix showed the
next best time was Wednesday 10am US-EDT, 1400 UTC. The only person
with a conflict, as luck would have it, was Yrs Truly. :-) My conflict
is now gone, so I would move to use this meeting time for our next
occurrence, and beyond.
That would be Wednesday, August 5, 10am US-EDT, 1400 UTC.
For/against?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 2 months
Summary of password strength discussion
by Michael Catanzaro
Hi,
At the last WG meeting [1] we discussed the password strength issue. We
agreed on four main points:
1) Fedora Workstation will ship a custom .conf file in
/etc/security/pwquality.conf.d, which is now possible in F23 [2].
2) gnome-initial-setup will be modified to prevent the user from
setting a password that would be rejected by libpwquality.
3) We need to test a reasonable set of passwords we'd want to succeed,
to make sure the settings we chose in (1) are correct.
4) Our requirements for local password strength will allow passwords
that would be much too weak were remote access via SSH to be enabled.
We should have some user interaction when enabling SSH in the Sharing
panel to force the user to pick a much stronger password.
Note: point (1) allows corporate deployments to set their own password
polices, which will be respected by GNOME, to meet their own security
needs, by modifying /etc/security/pwquality.conf (which overrides the
settings in /etc/security/pwquality.conf.d).
Point (4) above sets the goal of setting stricter password requirements
when remote access is enabled. Remote access is disabled by default and
will remain disabled forever for most Workstation users, so it's not
appropriate for that case to dictate our default password requirements.
This means only physical adversaries are interesting to consider.
We haven't yet discussed what is the reasonable set of passwords we'd
want to succeed. I propose the following starting point for this
discussion, from [2]: "In Fedora Workstation, we expect passwords to be
used to provide good security against nontechnical human beings with
physical access to the computer, physically typing away at the
keyboard. By default, they aren't intended to protect against
sophisticated adversaries. We therefore want to allow users to set much
weaker passwords than are currently permitted by libpwquality, since
longer passwords don't provide any practical benefit to most of our
users."
You might not worry about people breaking into your house to steal your
desktop computer, but we _should_ be concerned about laptops. But to
protect against a sophisticated physical adversary, disk encryption is
required and the local password is not very interesting.
We still need more effort to define what should be acceptable
passwords. One possibility: "Examples of acceptable passwords include
'berlin,' 'wombat,' and 'butter.' Any of these would work great at
keeping out a human typing on the keyboard." This implies that we
disable pwquality's use of cracklib in the pwquality configuration
file, and reduce the minimum acceptable characters down as far as
pwquality allows (6, I think).
Keep in mind that we've established that pwquality is not very good at
rating password strength.
[1] http://meetbot.fedoraproject.org/fedora-meeting/2015-07
-20/workstation.2015-07-20-13.00.log.html/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1241310
8 years, 2 months
Re: E&S WG request for input on requirements for Fedora Developer Portal
by Václav Pavlín
On 07/21/2015 10:22 AM, Nick Coghlan wrote:
> On 21 July 2015 at 18:10, Petr Hracek <phracek(a)redhat.com> wrote:
>> Hi Taylor,
>>
>> On 07/20/2015 10:12 PM, Owen Taylor wrote:
>>> On Mon, 2015-07-20 at 10:33 -0400, Jens Petersen wrote:
>>>> In the last Env & Stacks meeting last week there was discussion about
>>>> plans, direction, and content for the Fedora Developer Portal website
>>>> that is under construction. I think the plan is make the E&S WG more
>>>> actively involved in overseeing the content on the Portal. Anyway as
>>>> part
>>>> of the discussion it was suggested by Langdon that it would be good
>>>> to
>>>> reach out to the WS WG for input on its requirements and suggestions
>>>> for the Developer Portal since one of the main targets of Fedora WS
>>>> is
>>>> developers. Since I am on both WGs I offered to liase on this topic.
>>>>
>>>> What kind of content, requirements or suggestions does the WS WG have
>>>> for the Developer Portal?
>>> Hi Jens,
>>>
>>> I looked through the wiki page, and had a few questions/comments:
>>>
>>> * Is the target was exclusively on using Fedora as a client machine,
>>> or if it also is planned to cover using Mac/Windows to develop for
>>> deployment?
>> Yeah good point. Main target of Fedora Developer Portal is to allow users to
>> use a features or projects who use Fedora.
>> Window no. We have no plan currently to support it.
>> If there is going to be a volunteer who creates a page for Mac it would be
>> awesome
>> But for Windows I think that it is not possible;)
> Specifically for Linux container development, the combination of
> Vagrant + VirtualBox + some of the tooling the Project Atomic folks
> are putting together makes it feasible to have a cross-platform
> development story. The Eclipse based tooling is also cross platform.
>
> However, I don't think it makes sense to focus on that in the initial
> iterations, although it may be a good thing to add later.
Not only container development. With upcoming changes to DevAssistant
(client-server architecture, WebUI) we aim at using the server part in
VM (Vagrant, preferably) and client being either served by that VM
through WebUI or being just a thin client on the host (let's hope
someone will pick it up and write clients for both Mac and Windows:).
Then it should be easy to start development of (basically any) Linux
project on non-Linux system in any language or any framework (well, as
long as these have assistants available:) )
Cheers,
Vašek
>
>>> * For someone coming to the website, they shouldn't feel that they
>>> have to choose a language, a framework, a database, a deployment
>>> technology before they get started. This is likely to stop anybody but
>>> the most confident and experienced developer dead in their tracks. It's
>>> fine if there is information on the site about a wide range of topics,
>>> but we can't be afraid to make specific recommendations and orient the
>>> experience of coming to the site around those recommendations.
>>> (Probably a small set of recommendations rather than a single one,
>>> depending on what language, if any, the developer knows, and what they
>>> want to develop.)
>> Thanks for this.
>> More information can be found on our GitHub
>> https://github.com/developer-portal/content
>>
>> We would like to allow users e.g to try Vagrant/Docker/DevAssistant
>> and shows them how to install it and how to make their workstation suitable
>> for using or even developing.
> I think there are other recommendations we can draw on to say "If you
> don't have a preference, use this". Think of a decision tree like the
> one I suggested for deployment technologies, where we ask users
> questions they're likely to know the answer to, and suggest a suitable
> tech stack. We can also fall back on existing technology
> recommendations in the other WGs and Fedora Infrastructure.
>
> Probably another good one to defer, though - while I think we will
> want such a guide for the new deployment tools folks are working on,
> for this initial iteration of the site I think we're wanting to
> attract folks that are *already* developing with open source
> programming languages, and show them how to use their existing
> toolsets effectively on the Fedora, rather than specifically aiming to
> help complete beginners choose a suitable tech stack.
>
> Cheers,
> Nick.
>
--
Architect - Senior Software Engineer
Developer Experience
Brno, Czech Republic
Phone: +420 739 666 824
8 years, 2 months
E&S WG request for input on requirements for Fedora Developer Portal
by Jens-Ulrik Petersen
Hi,
In the last Env & Stacks meeting last week there was discussion about
plans, direction, and content for the Fedora Developer Portal website
that is under construction. I think the plan is make the E&S WG more
actively involved in overseeing the content on the Portal. Anyway as part
of the discussion it was suggested by Langdon that it would be good to
reach out to the WS WG for input on its requirements and suggestions
for the Developer Portal since one of the main targets of Fedora WS is
developers. Since I am on both WGs I offered to liase on this topic.
What kind of content, requirements or suggestions does the WS WG have
for the Developer Portal?
References:
https://fedoraproject.org/wiki/Websites/Developer
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/DeveloperPortal
Thanks, Jens
ps I planned to bring this up before the WS WG meeting today
but I got back late so posting it here now: not sure there would
have been time to discuss it in the irc meeting anyway...
8 years, 2 months
Workstation WG Recap 2015-Jul-20
by Paul W. Frields
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-07-20/workstation.20...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-07-20/workstation.20...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-07-20/workstation.20...
* * *
======================================
#fedora-meeting: Fedora Workstation WG
======================================
Meeting started by stickster at 13:00:45 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2015-07-20/workstation.20...
.
Meeting summary
---------------
* Roll call! (stickster, 13:01:27)
* Thanks and gratitude (stickster, 13:05:30)
* ACTION: stickster follow up on mailing list about switching meeting
times, since this is the second time in three meetings we've had
trouble reaching quorum (stickster, 13:09:22)
* Flock presence (stickster, 13:10:14)
* stickster, cschaller, and mclasen should be present at Flock (and
jwb) (stickster, 13:10:37)
* LINK: http://flocktofedora.org (stickster, 13:11:15)
* otaylor also attending (stickster, 13:11:37)
* ryanlerch also attending, thanks to some last-minute budget
wrangling (stickster, 13:14:54)
* BZ 1241310 -- password strength (stickster, 13:16:51)
* Some libpwquality changes are being made to allow weaker passwords,
but it's not yet clear this solves Workstation case. (stickster,
13:20:28)
* AGREED: on initial password plan (see log for full details)
(stickster, 13:59:21)
* ACTION: mcatanzaro Pull the plan to the list and kickstart
discussion on item 4 for sshd strength (stickster, 14:00:12)
* F23 Alpha freeze coming! (stickster, 14:00:28)
Meeting ended at 14:00:51 UTC.
Action Items
------------
* stickster follow up on mailing list about switching meeting times,
since this is the second time in three meetings we've had trouble
reaching quorum
* mcatanzaro Pull the plan to the list and kickstart discussion on item
4 for sshd strength
Action Items, by person
-----------------------
* mcatanzaro
* mcatanzaro Pull the plan to the list and kickstart discussion on
item 4 for sshd strength
* stickster
* stickster follow up on mailing list about switching meeting times,
since this is the second time in three meetings we've had trouble
reaching quorum
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (98)
* mcatanzaro (41)
* Corey84 (30)
* mclasen (22)
* otaylor (15)
* jwb (10)
* randomuser` (9)
* zodbot (7)
* juhp_ (6)
* corey84__ (1)
* rtcm (1)
* cmurf (1)
* rdieter_work (0)
* juhp (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8 years, 2 months
a couple of questions about wayland
by kendell clark
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
hi all
I'm wanting to start using gnome on wayland a lot more, so I can flush
out and fix any accessibility related issues. I have a couple of
questions though, and this seemed the right place to ask them. They're
mostly related to accessibility. In any graphical file manager, they
make their icons accessible by adding an image description to the icon
that orca reads. This enables orca to read, for example, test.txt
plain text document. So the image description is the mime type. I've
seen mimetypes such as, application/x-msword, for word documents.
xcontent/audioPlayer for audio players. Are those mime types tied into
xorg or does the "x" just represent an extension to the freedesktop
mime standard? I was hoping that when orca sees my audio player in the
computer it could say "sansa clip audioPlayer" instead of as it does
now, "sansa clip unknown". I'm completely ignorant of how all these
standards operate underneath the hood so if I'm way off the mark, I
apologize. I do know that when using wayland, gnome shell doesn't draw
the desktop, so no desktop icons. This is being worked on though so
it's not a huge deal. My next question is about keyboard shortcuts. If
we're transitioning to a new display server, would it be possible to
have universal keyboard shortcuts? That is, you could set up your
keyboard shortcuts in gnome, and if you switched over to mate, those
keyboard shortcuts would continue to work? I don't think this is
possible in xorg because of how xorg works, but in wayland, you could
set it up so that when mate connects, it is able to see that keyboard
shortcuts have been set, and map the desktop specific parts, such as
closing, moving, minimizing windows, etc to it's own internal methods
for doing so. This is probably not a huge priority since the hard task
will be getting graphics drivers to work properly but just thought I'd ask
Thanks for reading
Kendell clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVqEF+AAoJEGYgJ5/kqBTdPcEQAJZEy9hwZ9+Yo2mbt8l4fzgY
chBAozteadrn8rhn6UcFNWQAm8KpyuHY4h/bPuZ0p3wPt3v342+IV5uSYc2HYiiw
Ojdd8fColwIFOF7K7uLbOzz/uU31oFXOCeCY/EeMEmXbmQOCraphjr2vHPjC1GKl
IpEzGkFlRSyfOagPPKSdcMgXQFqVAeMigBCH2Sx0X5tCgINEWeWSHP719SYnqA1J
uAf7BYfqx/yLrwTj6X9NH/hLYTQS/CZRFevjdCt2UhmFuip2Y1T/xFbR3Nm14JqP
60DYRVTzeUX9N84Wq+aEsbWBAazjdz3oaXTBKv3YruxUo2Ibiy5vshb8ug3pzkbN
HlKu4Ahth5bn9QKtMNtRsGnXNpszYB16RCP/2rtcj1hklUkTxzXYeEBn442c550w
9LsLk+Q3J2QwI3975kiD2C7wr3TvycaMnmEstWLeT+CmPohuTFuNJ42SjhU38Dtk
dBM8WeRk0ojvTKlFxHaWwr2y/I3el1DvR0jrCYEKgCcGZiIbt11vujvI3yBbtdpt
cLLXToywFj+ta6MEFKnrblpm+y/T4WF6/shOycX5jRU7YRm6nVBrMjIC9OzOHl+e
2izg/qD1VjuiqWN6DavXpMzT3Z/0+8FU1UI2yDwrSn9VV0pHg+dsPw0HcqoQlG9W
jP/KcFttm5oD7KHJWjsg
=rLQL
-----END PGP SIGNATURE-----
8 years, 2 months
Re: GTK+3 WmClass changes on Wayland
by Adam Williamson
On Sun, 2015-07-12 at 08:21 -0600, Stefan Nuxoll wrote:
> A commit to GTK+3 back in March changed the way that GTK determines
> the WmClass, preferring the GApplication ID if it is set when running
> on Wayland [0]. This behavior causes gnome-shell to not match the
> applications to the relevant .desktop files, resulting in the
> GApplication ID being displayed in the app menu instead of the
> application name from the .desktop file.
>
> I have opened a bug against epiphany upstream [1], which is in the
> process of discussing the behavior, unless the GTK+ maintainers
> decide to revert the change this will affect any application that
> uses GApplication without a matching .desktop file name (Geary is
> another that I have noticed) if Fedora does make wayland the default
> in F23.
>
> I do not forsee the GTK+ maintainers reverting the change, using the
> Application ID as the WmClass by default makes much more sense in the
> application model and the transition to Wayland gives them a way to
> make the change in somewhat of a "clean break" fashion.
>
> [0] https://git.gnome.org/browse/gtk+/commit/gdk/wayland/gdkwindow
> -wayland.c?id=71256a0f94972be8220049b1c99dc2db61e56b5a
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=752258
This seems like it'd be best for desktop@, so CCing that list. Thanks
for the heads-up. As all good conspiracy theorists know there's a
fairly strong overlap / connection between GTK+ developers, GNOME
developers, and Fedora Workstation maintainers, soooo...:)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 2 months