yea it has option --sigkey, in older version of koji, "koji-1.2.6-1.20090109.1409.46.fc9.noarch" this version i have installed in server,

I understand why you asked this question, even i don't find this option on my client box that has newer version installed






V!jay


On Wed, Dec 15, 2010 at 12:50 AM, Mike McLean <mikem@redhat.com> wrote:


On 12/14/2010 03:45 AM, Vijay N. Majagaonkar wrote:

> Hi All,

>

> I m new to this system forgive me if i am doing something wrong here !

>

> We can add sing key to build-tag at the time of creating tag..

>

> [vijay@koji ~]$ koji add-tag --help

> Usage: koji add-tag [options] name

> (Specify the --help global option for a list of other help options)

>

> Options:

> * *-h, --help * * * show this help message and exit

> * *--parent=PARENT *Specify parent

> * *--arches=ARCHES *Specify arches

> * *--sigkey=SIGKEY *Specify signing key*



I'm not quite sure what you mean. Koji's add-tag subcommand does not and

has never supported a --sigkey option. Is this actual output or are you

proposing a new feature?

--

buildsys mailing list

buildsys@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/buildsys



--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Hi Pierre,

>
> I'am using Koji + sign_unsigned.py + mash to build RPM on CentOS5
>

I'm interested in hearing about this from you.

If you run sign_unsigned.py how can you be using mash to create yum repos?

>From what I can tell, mash can only work with Koji tags as a source and a file system path as a destination. Are you putting RPM headers back into koji then running mash?

Can you explain how you're doing this? (I am still a Koji neophyte, so go slow...)

> I have modified sign_unsigned.py to manage the passphrase. If
> option is not used, sign_unsigned.py gives an empty
> passphrase to 'rpm --resign' command.
>
> Add the Python expect module in import section (pexpect RPM
> must installed) :
>
> import getpass
> +import pexpect
>
> Add the --passwd option in __init__() from SignUnsigned class:
>
> + self.parser.add_option("--passwd", action="store_true")
>
> Replace these lines in do_signing()
>
> - # loop in case password is mistyped
> - while os.system(cmd):
> - # sleep briefly (give user a chance to ctrl-C)
> - time.sleep(2)
> + # Use expect to give the passphrase
> + # LANG=C to have english question 'pass phrase'
> + os.environ['LC_ALL'] = 'C'
> + child = pexpect.spawn(cmd)
> + # Wait for 'pass phrase'
> + child.expect('phrase:')
> + if not self.options.passwd:
> + child.sendline('
')
> + else:
> + child.sendline("%s" % self.options.passwd)
> + child.expect(pexpect.EOF)
>

And Thanks for patch! I think I will have a need for it.

/allen
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

Hi josh,

> 1) RPMs built in koji
> 2) sign_unsigned.py is run against various koji tags. Either
> dist-f1x-candidates or dist-f1x-updates-testing, or whichever
> need to be signed. NOTE: rawhide is not signed
> 3) mash is run against the tag after the RPMs have all been signed.
> 4) Bodhi does some symlink switching after all the mashes
> have completed successfully and the new repos are pushed to
> the mirrors.
>

This is more for my understanding, because I think I am already out of my comfort zone for managing my little amount of packages with Koji. Koji really helps me a lot w.r.t having a handfull of custom packages, it allows me to focus on the package and not the mess of yum/rpm dependency.

But, how do you get from step 2 to step 3? I went ahead and read Jesse's e-mail (great explanation, btw) and is this where the sigul system comes into play? Because working from my knowledge of Koji, it would appear to me that

A) the output of step 2 would be signed RPMs on a filesystem

B) how do you get the signed RPMs on disk (the filesystem) back into Koji? I think this is the process I have come across in previous posts from Jesse/Mike. I don't understand what sigul is could be the issue...

C) does step 3 mean that you have taken twice as much space on disk because know you have two versions (one signed and one unsigned) of the same NVR build?

D) if I go to Fedora's Koji, I don't see two NVR RPMs per package. I think I am missing something here w.r.t getting signed RPMs back into Koji.


Thanks for outline Josh,

-Allen
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 12/14/10 7:57 PM, Allen Hewes wrote:
> B) how do you get the signed RPMs on disk (the filesystem) back into
> Koji? I think this is the process I have come across in previous
> posts from Jesse/Mike. I don't understand what sigul is could be the
> issue...

Sigul is calling koji import-sig in order to import the signed header
from the signed rpm. Koji can keep any number of signed headers for a
package. You can then ask koji to write out a version of rpms with
signed headers. This is actually done through the API, there is no
command line option for it. (koji list-api to get a list of all the
possible API calls)

>
> C) does step 3 mean that you have taken twice as much space on disk
> because know you have two versions (one signed and one unsigned) of
> the same NVR build?

If you keep the signed one around yes. You don't have to sign every
build, or you don't have to keep the signed version around after you
publish them somewhere.

> D) if I go to Fedora's Koji, I don't see two NVR RPMs per package. I
> think I am missing something here w.r.t getting signed RPMs back into
> Koji.

http://kojipkgs.fedoraproject.org/packages/pungi/2.1.4/1.fc14/data/signed/97a1071f/noarch/
You'll see signed rpms there. The signature content gets put into the
<package>/<version>/<release>/data/ directory structure.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On Tue, Dec 14, 2010 at 09:00:23PM +0100, Oliver Falk wrote:
> Hi Jesse!
>
> Just want to mention, that sigul might be a bit too much effort for a
> private (or even corporate) koji setup...

sigul runs fine, also (with less security) on a koji server. And overall
it is also "just" about setting up a few config files and certs.
Signing rpms will increase the io load on the koji server...


regards,

Florian La Roche

--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 12/15/2010 07:46 AM, Florian La Roche wrote:
> On Tue, Dec 14, 2010 at 09:00:23PM +0100, Oliver Falk wrote:
>> Hi Jesse!
>>
>> Just want to mention, that sigul might be a bit too much effort for a
>> private (or even corporate) koji setup...
>
> sigul runs fine, also (with less security) on a koji server. And overall
> it is also "just" about setting up a few config files and certs.
> Signing rpms will increase the io load on the koji server...

But if you want to run sigul, you have security in mind.. Why would one
want to install it then on a less secured system? :-)

-of
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 12/14/2010 11:23 PM, Jesse Keating wrote:
> On 12/14/10 7:57 PM, Allen Hewes wrote:
>> B) how do you get the signed RPMs on disk (the filesystem) back into
>> Koji? I think this is the process I have come across in previous
>> posts from Jesse/Mike. I don't understand what sigul is could be the
>> issue...
>
> Sigul is calling koji import-sig in order to import the signed header
> from the signed rpm. Koji can keep any number of signed headers for a
> package. You can then ask koji to write out a version of rpms with
> signed headers. This is actually done through the API, there is no
> command line option for it. (koji list-api to get a list of all the
> possible API calls)

You can use koji write-signed-rpm to get it to write out a copy signed
with a previously imported signature. The API works too though.

>>
>> C) does step 3 mean that you have taken twice as much space on disk
>> because know you have two versions (one signed and one unsigned) of
>> the same NVR build?
>
> If you keep the signed one around yes. You don't have to sign every
> build, or you don't have to keep the signed version around after you
> publish them somewhere.
>
>> D) if I go to Fedora's Koji, I don't see two NVR RPMs per package. I
>> think I am missing something here w.r.t getting signed RPMs back into
>> Koji.
>
> http://kojipkgs.fedoraproject.org/packages/pungi/2.1.4/1.fc14/data/signed/97a1071f/noarch/
> You'll see signed rpms there. The signature content gets put into the
> <package>/<version>/<release>/data/ directory structure.
>

--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 12/15/10 5:48 AM, Mike Bonnet wrote:
>> > Sigul is calling koji import-sig in order to import the signed header
>> > from the signed rpm. Koji can keep any number of signed headers for a
>> > package. You can then ask koji to write out a version of rpms with
>> > signed headers. This is actually done through the API, there is no
>> > command line option for it. (koji list-api to get a list of all the
>> > possible API calls)
> You can use koji write-signed-rpm to get it to write out a copy signed
> with a previously imported signature. The API works too though.
>

Ah, I didn't see it in koji help --admin

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

On 12/14/2010 09:29 PM, Vijay N. Majagaonkar wrote:
> yea it has option --sigkey, in older version of koji,
> "koji-1.2.6-1.20090109.1409.46.fc9.noarch" this version i have installed in
> server,
>
>
> I understand why you asked this question, even i don't find this option on
> my client box that has newer version installed

I've search git and no commit has ever added it. In fact no command has
ever had a --sigkey option (only --key, --keytab, or --sigs). The
version you have installed on your server has either been strangely
modified (it's not even clear what associating a sigkey with a tag would
mean) or is experiencing some sort of bug.

You should compare /usr/bin/koji on your server to the version of
cli/koji from the koji-1.2.6-1.fc9 tag in git.
https://fedorahosted.org/koji/browser/cli/koji?rev=7899fb704fd33ace3654b569ec349b8b7b92098c
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys

I can send you diff of koji python file
Just for update siging of RPM file is working with our buid system


V!jay

On Dec 16, 2010, at 1:49 AM, Mike McLean <mikem@redhat.com> wrote:

> On 12/14/2010 09:29 PM, Vijay N. Majagaonkar wrote:
>> yea it has option --sigkey, in older version of koji,
>> "koji-1.2.6-1.20090109.1409.46.fc9.noarch" this version i have installed in
>> server,
>>
>>
>> I understand why you asked this question, even i don't find this option on
>> my client box that has newer version installed
>
> I've search git and no commit has ever added it. In fact no command has
> ever had a --sigkey option (only --key, --keytab, or --sigs). The
> version you have installed on your server has either been strangely
> modified (it's not even clear what associating a sigkey with a tag would
> mean) or is experiencing some sort of bug.
>
> You should compare /usr/bin/koji on your server to the version of
> cli/koji from the koji-1.2.6-1.fc9 tag in git.
> https://fedorahosted.org/koji/browser/cli/koji?rev=7899fb704fd33ace3654b569ec349b8b7b92098c
> --
> buildsys mailing list
> buildsys@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/buildsys
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys