Intro & observations

[Alejo Cerrat0]

Hi, my name is Alejo Cerrato, and I'm Marketing Director of a medium
size company in SoFla.

I'm very interested in improve my skills on Linux and colaborate with
the Fedora Project.

So far I've found that if you are not very skilled in Linux it is hard
to follow all the steps as they are indicated to succesfully become a
contributor. And I guess that there may be people willing to
colaborate, but without the minimum Linux skills to do so.

For some reason (and I'm not trying to get any help here in this list)
I can't validate my CLA. I wonder how many people got discouraged in
becoming  a contributor because of the complexity of the process, and
the intrinsec bureaucracy.

I understand at the same time that it has to be done in a secure environment.

I'm going to keep on trying and get my CLA validated asap.

But at the same time I'll like to help make this process easier for
the contributors-to-be,  people that may lack Linux knowledge but have
other skills that could help.

AlejoCerrato.//

[Karsten Wade]

On Mon, 2007-08-20 at 11:17 -0400, Alejo Cerrat0 wrote:
> Hi, my name is Alejo Cerrato, and I'm Marketing Director of a medium
> size company in SoFla.
>
> I'm very interested in improve my skills on Linux and colaborate with
> the Fedora Project.

Great; thanks for bringing yourself to this mailing list. :)
> So far I've found that if you are not very skilled in Linux it is hard
> to follow all the steps as they are indicated to succesfully become a
> contributor. And I guess that there may be people willing to
> colaborate, but without the minimum Linux skills to do so.
>
> For some reason (and I'm not trying to get any help here in this list)
> I can't validate my CLA. I wonder how many people got discouraged in
> becoming  a contributor because of the complexity of the process, and
> the intrinsec bureaucracy.
>
> I understand at the same time that it has to be done in a secure environment.
>
> I'm going to keep on trying and get my CLA validated asap.
>
> But at the same time I'll like to help make this process easier for
> the contributors-to-be,  people that may lack Linux knowledge but have
> other skills that could help.

These are good points.  It is a challenge to get involved, it shouldn't
be, and it's hard to know where to start in making it easier.

While we cannot do away with the CLA for certain kinds of contributions,
we can:

A. Encourage contributions that don't require a CLA, so are easier to do
(bugzilla, mailing list, IRC, etc.)

B. Find ways to make the CLA easier to agree to (such as a click-through
CLA for the wiki)

For A., we can make it easier for people to find and participate in
those groups.  We try to point out the value and existence:

http://fedoraproject.org/wiki/Communicate

For B., we have a project to use a click-through CLA for giving wiki
editing privileges.  We are waiting for a release of the wiki software
to do that.

- Karsten

[Davidson Paulo]

Hi,

2007/8/20, Karsten Wade :
> These are good points.  It is a challenge to get involved, it shouldn't
> be, and it's hard to know where to start in making it easier.

Recently as guided my fiancé on CLA creation process (she is now a
Fedora Ambassador - http://fedoraproject.org/wiki/NataliaWanick) and I
noted that all the instructions on creating PGP and SSH keys are based
in command line. This is an error because Fedora have the powerful and
simple Seahorse that allows users to manage your keys more easily than
I could imagine, so there is no reason to instruct people to use
another way.

Moreover, Fedora Account System does't recognize files signed with
Seahorse (on Nautilus, right-click on a file, Sign). Natalia was
unable to complete the CLA creation process using only graphic tools
shiped on Fedora, but she needed to open a terminal and type gpg -a
--sign [file]...

CLA creation is not a so hard process. There are just tw0 critical
steps, there are keys creating and signature validating. If we can
instruct people to do this using graphical tools, there will be no
dificulty to people create their CLA.

[Rahul Sundaram]

Davidson Rodrigues Paulo wrote:
> Recently as guided my fiancé on CLA creation process (she is now a
> Fedora Ambassador - http://fedoraproject.org/wiki/NataliaWanick) and I
> noted that all the instructions on creating PGP and SSH keys are based
> in command line. This is an error because Fedora have the powerful and
> simple Seahorse that allows users to manage your keys more easily than
> I could imagine, so there is no reason to instruct people to use
> another way.

Many developers prefer using command line programs for various reasons. 
So while you can document the graphical utilities better, the command 
line variants need to be retained. Feel free to edit the wiki and 
document using seahorse as a method there.
> Moreover, Fedora Account System does't recognize files signed with
> Seahorse (on Nautilus, right-click on a file, Sign). Natalia was
> unable to complete the CLA creation process using only graphic tools
> shiped on Fedora, but she needed to open a terminal and type gpg -a
> --sign [file]...

Did you file a bug report? If not please do so at 
http://hosted.fedoraproject.org/projects/fedora-infrastructure

Rahul

[Davidson Paulo]

2007/8/21, Rahul Sundaram :
> Many developers prefer using command line programs for various reasons.

Yes, but we [the developers] are the minority. We never can forget this.
> So while you can document the graphical utilities better, the command
> line variants need to be retained.

Right, this is part of the Free Software philosophy, that is, "do
things the way you want", not "I don't care if there is another way to
do that, do it the way I did".
> Feel free to edit the wiki and
> document using seahorse as a method there.

Yes, I'll do that soon. :-)
> Did you file a bug report? If not please do so at
> http://hosted.fedoraproject.org/projects/fedora-infrastructure

I'm not sure if this can be considered a bug because both Seahorse and
signature verification works as they were programmed to. I think this
is an issue for a feature request, not a bug report. Anyway, I'll send
a report using this channel (unless exists another more appropriate),
because just talking helps nobody.

Thanks,

Davidson

[Bryan Smith]

On Tue, 2007-08-21 at 10:46 -0300, Davidson Rodrigues Paulo wrote:
> Yes, but we [the developers] are the minority. We never can forget this.

If Fedora is catering to contributors, then there is that consideration.

Furthermore, some security aspects aren't merely "Point'n Click."  As
someone who has done policies & procedures for banks, forcing people to
use a process is not optional, and I don't know how many times I caught
key people giving out or assuming authentications were actual, when they
were not.
> Right, this is part of the Free Software philosophy, that is, "do
> things the way you want", not "I don't care if there is another way to
> do that, do it the way I did".

I'm not seeing your point there.  My apologies if I'm assuming here.

There is a reason why there is _always_ a "command line interface" (CLI)
to every program, it's the "most common denominator."  Graphical user
interfaces (GUI) should never cross CLI interfaces, _only_ complement.
The GNU project and standards has drastically improved these standards
over previous UNIX efforts.  And there are reasons why the system may
need to be configurable outside the GUI as well.  ;)

As an original NT 3.1 beta tester through today as a person who
regularly "retrains" (i.e., "deprograms") Windows sysadmins to "think
multiuser, think piecemeal, think security" like UNIX/Linux, I have
volumes on what NT absolutely screws up on and lacks standards when it
comes to this -- often to the ultimate demise of Microsoft Professionals
who, eventually, do not tolerate it.
> I'm not sure if this can be considered a bug because both Seahorse and
> signature verification works as they were programmed to. I think this
> is an issue for a feature request, not a bug report. Anyway, I'll send
> a report using this channel (unless exists another more appropriate),
> because just talking helps nobody.

[Davidson Paulo]

2007/8/21, Bryan J. Smith :
> Furthermore, some security aspects aren't merely "Point'n Click."  As
> someone who has done policies & procedures for banks, forcing people to
> use a process is not optional, and I don't know how many times I caught
> key people giving out or assuming authentications were actual, when they
> were not.

Hey, I'm absolutely not sugesting to modify security policy, I hope
you have understood it. I'm talking about an *altervative* method to
generate PGP/SSH keys and sign files in a way they can be recognized
by Fedora Account System engine. Because, today, there no one
information about using a GUI to generate PGP/SSH keys.
> I'm not seeing your point there.  My apologies if I'm assuming here.

I said if you think that command line is better you can't say to
others they can't use a GUI, as well as anyone who think that using a
GUI is better can't say to others they can't use command line.
> There is a reason why there is _always_ a "command line interface" (CLI)
> to every program, it's the "most common denominator."

Yes, I know it. I use CLI every day, every time because at most cases
giving commands allows me to do tasks in a faster way than using
GUI's. But this is not the issue.
> Graphical user
> interfaces (GUI) should never cross CLI interfaces, _only_ complement.

Yes, it's right. I never said Fedora need to avoid using CLI
interfaces on its CLA process. Again, this is not the issue.

Regards,

Davidson

[Bryan J. Smith]

Davidson Rodrigues Paulo  wrote:
> Hey, I'm absolutely not sugesting to modify security policy,
> I hope you have understood it. I'm talking about an *altervative*
> method to generate PGP/SSH keys and sign files in a way they can
> be recognized by Fedora Account System engine. Because, today,
> there no one information about using a GUI to generate PGP/SSH
> keys.

That's typically because there is no "Point'n Click" 'process.'  Yes,
there are key managers and other GUI solutions, but the "process"
(including the concepts of "Public Key" authentication in general) is
what most people take issue with.  ;)
> I said if you think that command line is better you can't
> say to others they can't use a GUI, as well as anyone who
> think that using a GUI is better can't say to others they
> can't use command line.

If you have a GUI that "does the job," go for it.  In fact, I guess
we could use a "wizard" that has major "hand holding."  God knows I'd
love to write such a key manager that does.  But I haven't seen one
myself.  ;)

I.e., I found the commercial PGP GUI software is "too hard to use" by
97% of users, not because of the software or GUI, but because of the
concepts beyond PKI.
> Yes, I know it. I use CLI every day, every time because at most
> cases giving commands allows me to do tasks in a faster way than
> using GUI's. But this is not the issue.

But the "processes" are the issue.  I don't know how you avoid them
in a GUI, at least without a Wizard that is also an educator.

The ultimate irony is that most people say, "I just want it to work"
and don't stop to realize part of the "process" *IS* to understand
*WHY* you don't "just want it to work."  I.e., what protections and
processes you must proliferate, not, for example ...

"okay, I got a key, not sure which one you need so
   I'll upload both of them to you."  ;)

[ Oh man, that happens *WAY* too much! ]
> Yes, it's right. I never said Fedora need to avoid using CLI
> interfaces on its CLA process. Again, this is not the issue.

I know, but the "process" is what people complain about, not the GUI.
 ;)

[Bryan Smith]

Davidson Rodrigues Paulo  wrote:
> Hey, I'm absolutely not sugesting to modify security policy,
> I hope you have understood it. I'm talking about an *altervative*
> method to generate PGP/SSH keys and sign files in a way they can
> be recognized by Fedora Account System engine. Because, today,
> there no one information about using a GUI to generate PGP/SSH
> keys.

That's typically because there is no "Point'n Click" 'process.'  Yes,
there are key managers and other GUI solutions, but the "process"
(including the concepts of "Public Key" authentication in general) is
what most people take issue with.  ;)
> I said if you think that command line is better you can't
> say to others they can't use a GUI, as well as anyone who
> think that using a GUI is better can't say to others they
> can't use command line.

If you have a GUI that "does the job," go for it.  In fact, I guess
we could use a "wizard" that has major "hand holding."  God knows I'd
love to write such a key manager that does.  But I haven't seen one
myself.  ;)

I.e., I found the commercial PGP GUI software is "too hard to use" by
97% of users, not because of the software or GUI, but because of the
concepts beyond PKI.
> Yes, I know it. I use CLI every day, every time because at most
> cases giving commands allows me to do tasks in a faster way than
> using GUI's. But this is not the issue.

But the "processes" are the issue.  I don't know how you avoid them
in a GUI, at least without a Wizard that is also an educator.

The ultimate irony is that most people say, "I just want it to work"
and don't stop to realize part of the "process" *IS* to understand
*WHY* you don't "just want it to work."  I.e., what protections and
processes you must proliferate, not, for example ...

"okay, I got a key, not sure which one you need so
   I'll upload both of them to you."  ;)

[ Oh man, that happens *WAY* too much! ]
> Yes, it's right. I never said Fedora need to avoid using CLI
> interfaces on its CLA process. Again, this is not the issue.

I know, but the "process" is what people complain about, not the GUI.
 ;)

[Davidson Paulo]

2007/8/21, Bryan J. Smith :
> That's typically because there is no "Point'n Click" 'process.'  Yes,
> there are key managers and other GUI solutions, but the "process"
> (including the concepts of "Public Key" authentication in general) is
> what most people take issue with.  ;)

No. This is what the people say. The process is simple, when the tools
are simple. In other words, give to people tools that make more easy
to execute each step of the process and the entire process will looks
easy for them.
> The ultimate irony is that most people say, "I just want it to work"
> and don't stop to realize part of the "process" *IS* to understand
> *WHY* you don't "just want it to work."  I.e., what protections and
> processes you must proliferate, not, for example ...
>
> "okay, I got a key, not sure which one you need so
>    I'll upload both of them to you."  ;)
>
> [ Oh man, that happens *WAY* too much! ]

Welcome to the Earth. :-)
> I know, but the "process" is what people complain about, not the GUI.

If a computer don't turns on, the owner will say to the technician "My
computer don't turns on", not "My computer don't turns on because one
of the RAM modules". Do you understand? We have an issue with the
process, but we need to know that the problem is not the process
itself, same way as the problem with the computer is not the computer,
but something inside it that the owner don't know what it and the
technician needs to discover.

[Bryan Smith]

Davidson Rodrigues Paulo  wrote:
> No. This is what the people say. The process is simple, when the
> tools are simple.

Okay, then create the CGI characters for the next, animated film. 
The tools are easy.  So just go do it.

Oh, wait, that's right, there are concepts involved that software
can't teach you.  At _most_ you could create a wizard that creates a
"stock" character with a few options, and a few animations.

But that still doesn't get you to film.  ;)
> Welcome to the Earth. :-)

One person does that and BAM!  Fedora potentially compromised!
> If a computer don't turns on, the owner will say to the technician
> "My computer don't turns on", not "My computer don't turns on
> because one of the RAM modules".

And what do they do when the technician states, "I need your password
to fix your computer."  That's authentication 101.  Now multiple the
complexity of the concepts by an order of magnitude.  Welcome to
public key authentication.  ;)
> Do you understand?

Apparently you didn't understand mine.

Also understand you are talking to someone who stared down the
executives at the #1 entertainment company going, "no, Capital One
will sign their files."

Someone who said, "no, your support technicians will not support bank
servers on the WAN, they will go over to a separate room and login in
there, because it is on a completely different LAN with absolutely no
Internet or other corporate WAN (let alone inter-company)
connectivity."
> We have an issue with the process, but we need to know that
> the problem is not the process itself, same way as the problem
> with the computer is not the computer,
> but something inside it that the owner don't know what it and the
> technician needs to discover.

I have heard the "the processes are too difficult, to hard, we need a
'tool' that is 'secure' and people don't need to understand how they
work."  Sorry, doesn't fly with me on _basic_ security concepts.

Especially when just *1* user compromised means the _entire_ Fedora
project in compromised.  Tools don't help that.  ;0

A wizard is nice, but that wizard must _train_ the person on the
process.  They can_not_ just ignore the details.  So yes, that means
the user needs to know when its the memory, and when its not.  ;)

[Davidson Paulo]

2007/8/21, Bryan J. Smith :
> A wizard is nice, but that wizard must _train_ the person on the
> process.  They can_not_ just ignore the details.

So, are CLI that make people know the details?

[Bryan Smith]

Davidson Rodrigues Paulo  wrote:
> So, are CLI that make people know the details?

My point is that the GUI may not any more than the CLI, and could
possibly make it worse.  Again, I'm _not_ debating CLI v. GUI, so
_please_ drop that.  ;)

I said *IF* a GUI is to be built, it _should_ be a "wizard."  And
that "wizard" is educational, not just a "cookbook" type of "generate
me a keypair."  ;)

[Davidson Paulo]

2007/8/21, Bryan J. Smith :
> I said *IF* a GUI is to be built, it _should_ be a "wizard."  And
> that "wizard" is educational, not just a "cookbook" type of "generate
> me a keypair."  ;)

Education is a task for documentation, not software. When people
follow CLA instructions they need to be educated in PGP keys, not when
they are creating the keys.

I'm not talking about GUI building, wizards or user education. From the start:

* There is a GUI that works in a way it need to work, and it's so
"educational" than the CLI;

* Using GUI, we can sign a file, but it's not possible finish a CLA
validation signing the file this way because the file is signed as in
"gpg -b --sign [file]", and the Fedora Account System is configured to
recognized files signed as in "gpg -a --sign [file]";

* Making some modifications in the GUI that allow users to sign a file
in a way that is compatible with Fedora Account System will give them
a new way to create their CLA without modifying absolutely nothing in
the process (just in _one tool_ used to acomplish _two steps_ of the
process);

Is that, nothing else.

[Bryan Smith]

Davidson Rodrigues Paulo  wrote:
> Education is a task for documentation, not software.

I disagree.  But, ironically, the CLI addresses that today.  ;)
> When people follow CLA instructions they need to be educated
> in PGP keys, not when they are creating the keys.

Now I'm confused.  How does this make everything "easier"?

And are you advocating them creating the keys _then_ understanding?
Or vice-versa?
> I'm not talking about GUI building, wizards or user education.
> From the start:
> There is a GUI that works in a way it need to work, and it's so
>
> "educational" than the CLI;

I didn't understand that statement, and I'm still scratching my head
on what you mean by "works in a way it need to work"?
> Using GUI, we can sign a file, but it's not possible finish a CLA
>
> validation signing the file this way because the file is signed as
> in "gpg -b --sign [file]", and the Fedora Account System is
> configured to recognized files signed as in "gpg -a --sign [file]";

That's a simple binary v. ASCII aspect.  I'm still confused here.
Is there not the option radio button to change this already?
Or are you talking about changing defaults in GUI programs?
> Making some modifications in the GUI that allow users to sign a
>
> file in a way that is compatible with Fedora Account System will
> give them a new way to create their CLA without modifying
> absolutely nothing in the process (just in _one tool_ used to
> acomplish _two steps_ of the process);
> Is that, nothing else.

I'm still utterly confused here.  I guess I'm just clueless.

[Rahul Sundaram]

Bryan J. Smith wrote:
> Davidson Rodrigues Paulo  wrote:
> > Education is a task for documentation, not software.
>
> I disagree.  But, ironically, the CLI addresses that today.  ;)
> > When people follow CLA instructions they need to be educated
> > in PGP keys, not when they are creating the keys.
>
> Now I'm confused.  How does this make everything "easier"?

Please continue this discussion offlist if needed. I would rather this 
energy be focused on fixing any issues with the documentation and get 
over the problem.

Rahul

[Bryan Smith]

Rahul Sundaram  wrote:
> Please continue this discussion offlist if needed. I would rather
> this energy be focused on fixing any issues with the documentation
> and get over the problem.

Agreed.  My apologies.

[Nicolas Mailhot]

Le Mar 21 août 2007 15:46, Davidson Rodrigues Paulo a écrit :
> 2007/8/21, Rahul Sundaram :
> > So while you can document the graphical utilities better, the
> > command
> > line variants need to be retained.
>
> Right, this is part of the Free Software philosophy, that is, "do
> things the way you want", not "I don't care if there is another way to

GUI has the slight problem it's nightmarish to document, because the
UI can be localised (and the localisation may be unstable), themes
interfere, GUI devs like to change their UI every few releases, and
you can't assume the same utilities are installed on KDE and GNOME
desktops. That's why almost no one uses help pages for GUI tools,
because they seem to get out of date all the time by design.

Documentation is not impossible to do, but it requires several orders
of magnitude more work than the CLI.

[Davidson Paulo]

2007/8/21, Rahul Sundaram :
> So while you can document the graphical utilities better, the command
> line variants need to be retained. Feel free to edit the wiki and
> document using seahorse as a method there.

Old thread, but I finally found a way to sign CLA using only GUI
tools. Following are the wiki pages that I modified, including
instructions on how to sign CLA using GUI methods:

* http://fedoraproject.org/wiki/DocsProject/UsingGpg/CreatingKeys
 * http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo

There are the drafts I wrote before updating wiki pages:

* http://fedoraproject.org/wiki/DavidsonPaulo/Drafts/DocsProject/UsingGpg/Crea...
 * http://fedoraproject.org/wiki/DavidsonPaulo/Drafts/Infrastructure/AccountSys...

Obs.: instructions on how to sign CLA using command line tool are untouched.

Regards,