Bug 1812961 - Review Request: openosc - Open Object Size Checking Library to detect buffer overflows with built-in metrics
Summary: Review Request: openosc - Open Object Size Checking Library to detect buffer ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Robert-André Mauchin 🐧
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-12 15:15 UTC by yonhan
Modified: 2020-07-20 01:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-19 02:19:29 UTC
Type: ---
zebob.m: fedora-review+


Attachments (Terms of Use)

Description yonhan 2020-03-12 15:15:34 UTC
Spec URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01303303-openosc/openosc.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01303303-openosc/openosc-1.0.0-1.fc33.src.rpm
Description: OpenOSC is an open-source object size check library written in C. It has been developed in order to promote the use of compiler builtin object size check capability for enhanced security. It provides robust support for detecting buffer overflows in various functions that perform operations on memory and strings. Not all types of buffer overflows can be detected with this library, but it does provide an extra level of validation for some functions that are potentially a source of buffer overflow flaws. It protects both C and C++ code.
Fedora Account System Username: yonhan

This OpenOSC package is also hosted in COPR:
https://copr.fedorainfracloud.org/coprs/yonhan/openosc/

It has built successfully for all active releases, except for Magiea 5/6/7, due to a configure issue on Magiea 5/6/7. It builds successfully on Magiea 8 and later releases where that configure issue is fixed.

This is my first Fedora package, so I need a sponsor. It would be greatly appreciated if you can sponsor me. Thanks.

Comment 1 yonhan 2020-03-12 16:17:49 UTC
Blocks: 177841

Comment 3 yonhan 2020-03-12 16:30:56 UTC
(In reply to yonhan from comment #0)
> Spec URL:
> https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-
> rawhide-x86_64/01303303-openosc/openosc.spec
> SRPM URL:
> https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-
> rawhide-x86_64/01303303-openosc/openosc-1.0.0-1.fc33.src.rpm
> Description: OpenOSC is an open-source object size check library written in
> C. It has been developed in order to promote the use of compiler builtin
> object size check capability for enhanced security. It provides robust
> support for detecting buffer overflows in various functions that perform
> operations on memory and strings. Not all types of buffer overflows can be
> detected with this library, but it does provide an extra level of validation
> for some functions that are potentially a source of buffer overflow flaws.
> It protects both C and C++ code.
> Fedora Account System Username: yonhan
> 
> This OpenOSC package is also hosted in COPR:
> https://copr.fedorainfracloud.org/coprs/yonhan/openosc/
> 
> It has built successfully for all active releases, except for Magiea 5/6/7,
> due to a configure issue on Magiea 5/6/7. It builds successfully on Magiea 8
> and later releases where that configure issue is fixed.
> 
> This is my first Fedora package, so I need a sponsor. It would be greatly
> appreciated if you can sponsor me. Thanks.

Blocks: 177841 [https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR]

Comment 4 Artur Frenszek-Iwicki 2020-03-13 13:00:16 UTC
>Group:          System Environment/Libraries
>Group: Development/Libraries
The "Group:" tag is not used in Fedora.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections

>%install
>rm -rf $RPM_BUILD_ROOT
Don't do this.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections

>Source0:        %{name}-%{version}.tar.gz
Downloadable URLs are preferred. You can use "https://github.com/cisco/openosc/archive/v%{version}/openosc-%{version}.tar.gz" here.

Also, I'm not too familiar with using static libraries, but - wouldn't you need the header files, either way? The -static package should probably have a Requires: on the -devel package.

Comment 5 yonhan 2020-03-14 18:52:43 UTC
Hi Artur,

Thanks for the comments! I will fix all of them.

Yongkui

Comment 6 yonhan 2020-03-14 19:23:08 UTC
Spec file updated:

Spec URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-31-x86_64/01305433-openosc/openosc.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-31-x86_64/01305433-openosc/openosc-1.0.0-1.fc31.src.rpm

The same build results as before:
https://copr.fedorainfracloud.org/coprs/yonhan/openosc/build/1305433/

I also run rpmlint on the Spec file and SRPM:

rpmlint openosc.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
rpmlint openosc-1.0.0-1.fc31.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Comment 7 Mattia Verga 2020-03-15 10:05:18 UTC
Yongkui, you may want to have a look at this section about packaging static libraries:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries

Also, since upstream is on Github, you may want to use the new %forgemeta macro (this is not strictly needed, it's up to packager tastes):
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/

Comment 8 yonhan 2020-03-15 16:24:21 UTC
Hi Mattia,

Thanks for the comments!

I checked the section about packaging static libraries, and I think I do need the static library, and I put it in a separate openosc-static rpm. so it should be fine in my opinion.

The new %forgemeta works pretty well for openosc, and I like it.

Here is the new rpm build results:
https://copr.fedorainfracloud.org/coprs/yonhan/openosc/build/1305696/

Comparing with the old rpm build results at https://copr.fedorainfracloud.org/coprs/yonhan/openosc/build/1305433/, it failed for epel and opensuse (which probably does not yet support the new $forgemeta macro), but I guess we only care Fedora, so it should be fine.

Here is the updated spec and SRPM after using the new %forgemeta macro:

Spec URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-31-x86_64/01305696-openosc/openosc.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-31-x86_64/01305696-openosc/openosc-1.0.0-1.fc31.src.rpm

rpmlint results also look good:

rpmlint openosc.spec openosc-1.0.0-1.fc31.src.rpm
1 packages and 1 specfiles checked; 0 errors, 0 warnings.

Comment 9 yonhan 2020-03-17 17:45:24 UTC
I wonder if there are further comments for this package request review.

Also, if someone can sponsor me, it would be greatly appreciated!

Comment 10 Robert-André Mauchin 🐧 2020-03-26 18:31:40 UTC
 - You're missing isa parts:

Requires: openosc%{?_isa} = %{version}-%{release}

 - we don't package libtool archives, you should remove this file in %install

%{_libdir}/lib*.la

 - In order to avoid unintentional soname bump, you should not glob the major soname version, instead be more specific:

%{_libdir}/lib*.so.0*

 - RPM build errors:
+ cd openosc-1.0.0
/var/tmp/rpm-tmp.d9GN6u: line 38: cd: openosc-1.0.0: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.d9GN6u (%prep)
    Bad exit status from /var/tmp/rpm-tmp.d9GN6u (%prep)

  Use:

%autosetup -n OpenOSC-%{version}


Package approved.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Package does not contain any libtool archives (.la)
  Note: openosc-static : /usr/lib64/libopenosc.la
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/#packaging-static-libraries


===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig not called in %post and %postun for Fedora 28 and later.
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated", "Expat License", "GPL (v2 or later)",
     "Apache License 2.0". 32 files have unknown license. Detailed output
     of licensecheck in /home/bob/packaging/review/openosc/review-
     openosc/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Package requires other packages for directories it uses.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: Static libraries in -static or -devel subpackage, providing -devel if
     present.
     Note: Package has .a files: openosc-static.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[!]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in openosc-
     devel , openosc-tools , openosc-static
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: openosc-1.0.0-1.fc33.x86_64.rpm
          openosc-devel-1.0.0-1.fc33.x86_64.rpm
          openosc-tools-1.0.0-1.fc33.x86_64.rpm
          openosc-static-1.0.0-1.fc33.x86_64.rpm
          openosc-debuginfo-1.0.0-1.fc33.x86_64.rpm
          openosc-debugsource-1.0.0-1.fc33.x86_64.rpm
          openosc-1.0.0-1.fc33.src.rpm
openosc.x86_64: W: no-documentation
openosc-devel.x86_64: W: no-documentation
openosc-tools.x86_64: W: spelling-error %description -l en_US tracebacks -> trace backs, trace-backs, racetracks
openosc-tools.x86_64: W: no-documentation
openosc-tools.x86_64: W: no-manual-page-for-binary oscdecode.py
openosc-tools.x86_64: W: no-manual-page-for-binary oscmetrics.py
openosc-static.x86_64: W: no-documentation
7 packages and 0 specfiles checked; 0 errors, 7 warnings.

Comment 11 Robert-André Mauchin 🐧 2020-03-26 18:32:21 UTC
Package *not* approved. Sorry I'm tired, please fix the issues first.

Comment 12 yonhan 2020-04-05 20:49:28 UTC
Sorry for late response, and thanks for your comments!

I did all the fixes. Since I changed the source code, I bumped the package version from v1.0.0 to v1.0.1 version.

Spec file updated:

Spec URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01328497-openosc/openosc.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01328497-openosc/openosc-1.0.1-1.fc33.src.rpm

The Copr build results:
https://copr.fedorainfracloud.org/coprs/yonhan/openosc/build/1328497/

I added the below in Makefile.am to explicitly delete libopenosc.la file upon installation. I hope this is the right fix for autotools.

install-exec-hook:
        cd $(DESTDIR)$(libdir) && rm $(lib_LTLIBRARIES

Let me know if you have further comments.

Comment 13 Robert-André Mauchin 🐧 2020-04-13 18:20:11 UTC
%prep
%autosetup -n openosc-%{version}


the folder in the archive is OpenOSC-%{version} as I said before. The archive in the SRPM is not the same as the one downloaded on Github, please fix that.

Comment 14 yonhan 2020-04-14 15:16:03 UTC
Hi Robert,

Thanks for the comments!

Yes, I did try using "%autosetup -n OpenOSC-%{version}" in the openosc.spec file, which however caused the below build error:

+ cd OpenOSC-1.0.1
/var/tmp/rpm-tmp.rNYapH: line 39: cd: OpenOSC-1.0.1: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.rNYapH (%prep)

and if I change it to "%autosetup -n openosc-%{version}", then the build succeeds.

The openosc.spec in the github wants to support more Linux distros, not just Fedora, because some distros do not support forgeurl yet. Also the openosc.spec in the github is intended to work for the latest version, not just a specific release version.

My understanding for Fedora package is to use a specific stable version of OpenOSC, not the latest version of OpenOSC. Is my understanding correct?

Let me build a new SRPM that matches exactly to the one downloaded on Github.

will submit a new Copr build very soon.

Again Thank you for your comments!

Comment 16 yonhan 2020-04-14 18:59:36 UTC
Regarding that OpenOSC-1.0.1 vs. openosc-1.0.1 issue, I prefer to always use lower-case openosc, to avoid any such upper-case vs. lower-case issue.

When I download the tarball file, it is openosc-1.0.1.tar.gz file, however, when I extract it, the directory name is called OpenOSC-1.0.1, which is confusing. Robert, do you know how to configure github to use openosc-1.0.1 directory instead of OpenOSC-1.0.1 directory?

drwxrwxr-x. 10 rtd rtd   4096 Apr 14 12:53 OpenOSC-1.0.1
-rw-rw-r--.  1 rtd rtd 482277 Apr 14 11:08 openosc-1.0.1.tar.gz

Comment 17 yonhan 2020-05-07 19:07:20 UTC
Hi Robert,

I have updated the openosc.spec for the latest OpenOSC-1.0.2 version. and I have changed to %autosetup -n OpenOSC-%{version} in the openosc.spec file. All builds passed.

Spec file updated:

Spec URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01372234-openosc/openosc.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/yonhan/openosc/fedora-rawhide-x86_64/01372234-openosc/openosc-1.0.2-1.fc33.src.rpm

The Copr build results:
https://copr.fedorainfracloud.org/coprs/yonhan/openosc/build/1372234/

Let me know if you have further comments.

Thanks!
Yongkui

Comment 18 Jeff Law 2020-05-10 21:59:31 UTC
Robert-Andre,

Is there something Yongkui  could be doing to move this forward?  Red Hat's tools team is definitely interested in poking at openosc to see if/how it can be used to evaluate the effectiveness of FORTIFY_SOURCE and improvements that are made in that area (particularly as we spin up LTO-by-default) and as a potential alternate implementation.

If there's something Red Hat's tools team can/should be doing to help move this package forward, don't hesitate to let me know.

Thanks,

Jeff

Comment 19 Robert-André Mauchin 🐧 2020-06-14 18:12:19 UTC
Sorry I was away for health reasons.


Package approved.

Comment 20 yonhan 2020-06-22 16:36:48 UTC
hi Robert-Andre,

Thank you very much for the approval!

I think the next step for me is to follow the below wiki:
https://fedoraproject.org/wiki/Package_Review_Process

I will use the fedpkg tool to request a git repository for it.

Thanks!

Yongkui

Comment 21 yonhan 2020-06-22 18:27:20 UTC
hi Robert-Andre,

I have successfully done the below:

vim ~/.config/rpkg/fedpkg.conf
fedpkg request-repo openosc 1812961
https://pagure.io/releng/fedora-scm-requests/issue/26022

Then I run into the below error:

fedpkg -v --user yonhan clone openosc
Cloning ssh://yonhan@pkgs.fedoraproject.org/rpms/openosc
Running: git clone ssh://yonhan@pkgs.fedoraproject.org/rpms/openosc --origin origin
Cloning into 'openosc'...
ssh: connect to host pkgs.fedoraproject.org port 22: Connection timed out
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

This seems caused by firewall? or I need to wait for some time and retry?
I can do "git clone" with https URL, but perhaps cannot with ssh URL.

Comment 22 yonhan 2020-06-22 19:19:07 UTC
I also tried to clone it anonymously, failed with the below error message:

fedpkg -v  clone -a openosc
Cloning https://src.fedoraproject.org/rpms/openosc.git
Running: git clone https://src.fedoraproject.org/rpms/openosc.git --origin origin
Cloning into 'openosc'...
fatal: repository 'https://src.fedoraproject.org/rpms/openosc.git/' not found
Could not execute clone: Failed to execute command.

Comment 23 Artur Frenszek-Iwicki 2020-06-22 20:18:09 UTC
Repositories on src.fedoraproject.org are created manually by members of the Release Enginnering team in response to opened tickets. Your pagure.io/releng ticket is still open. You'll need to wait a bit for someone to pick it up and process it. You'll receive a notification from pagure when that happens.

Comment 24 yonhan 2020-06-22 20:41:42 UTC
HI Artur,

Thanks for the info. I will wait for the notification from pagure.

Thanks!
Yongkui

Comment 25 yonhan 2020-07-02 14:57:12 UTC
Hi Artur,

I haven't received any notification. Do you know how to check the status of the open tickets?

Thanks,
Yongkui

Comment 26 Artur Frenszek-Iwicki 2020-07-03 05:24:31 UTC
Check out the link to the pagure.io/releng ticket you posted earlier: https://pagure.io/releng/fedora-scm-requests/issue/26022

> Closed as Invalid
> The Bugzilla bug's review is approved by a user that is not a packager

Hm. Weird. Robert-André definitely is a packager. Try again maybe?

Comment 27 yonhan 2020-07-03 17:55:45 UTC
OK, I just created a new ticket:

https://pagure.io/releng/fedora-scm-requests/issue/26818

Let's see if this one can work for me.

Comment 28 yonhan 2020-07-03 21:36:16 UTC
This new ticket run into the exact same issue as the previous #26022 ticket.

#26818 New Repo for "rpms/openosc" 
Closed: Invalid 2 hours ago by limb.

The Bugzilla bug's review is approved by a user that is not a packager

Comment 29 Mattia Verga 2020-07-04 07:40:47 UTC
Actually, I can't find any user neither in the Packager group or in the Signed CLA Group with the email address of "zebob.m@gmail.com"...

Comment 30 Mattia Verga 2020-07-04 07:43:17 UTC
...also, yonhan@cisco.com has not been sponsored in the packager group and is not in the signed CLA group

Comment 31 Mattia Verga 2020-07-04 08:02:26 UTC
Sorry, my fault, it seems that fas search doesn't work with email addresses, only usernames... I thought it worked in the past.
So, Robert André IS in packager group with the same email of BZ. Yonhan, have you been sponsored in the packager group and have you signed the CLA?

I've opened a ticket on fedora infra to check what's wrong:
https://pagure.io/fedora-infrastructure/issue/9110

Comment 32 Robert-André Mauchin 🐧 2020-07-04 08:39:06 UTC
(In reply to Mattia Verga from comment #29)
> Actually, I can't find any user neither in the Packager group or in the
> Signed CLA Group with the email address of "zebob.m@gmail.com"...

My FAS is "eclipseo"

yonhan didn't sign the CLA nor is sponsored:

10:37:58   zodbot | User: yonhan, Name: Yongkui Han, email: yonhan@cisco.com, Creation: 2020-03-11, IRC Nick: None, Timezone: UTC, Locale: C, GPG key ID: None, Status: active
10:38:01   zodbot | Approved Groups: None

Comment 33 Mattia Verga 2020-07-04 08:54:11 UTC
(In reply to Robert-André Mauchin 🐧 from comment #32)
> (In reply to Mattia Verga from comment #29)
> > Actually, I can't find any user neither in the Packager group or in the
> > Signed CLA Group with the email address of "zebob.m@gmail.com"...
> 
> My FAS is "eclipseo"
> 
> yonhan didn't sign the CLA nor is sponsored:
> 
> 10:37:58   zodbot | User: yonhan, Name: Yongkui Han, email:
> yonhan@cisco.com, Creation: 2020-03-11, IRC Nick: None, Timezone: UTC,
> Locale: C, GPG key ID: None, Status: active
> 10:38:01   zodbot | Approved Groups: None

So, I suppose the error message returned by fedora-scm-request is misleading and is in fact due to the submitter not being approved into the packager group.

Comment 34 Robert-André Mauchin 🐧 2020-07-06 13:33:34 UTC
Sponsored. You can now request the repo. I sent you a mail with more detailed instructions.

Comment 35 Gwyn Ciesla 2020-07-06 20:55:11 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/openosc

Comment 36 yonhan 2020-07-07 19:02:56 UTC
hi All,

I run into below error when cloning my openosc repo:

[rtd@bxb-rtd-vm20 fedora-scm]$ fedpkg -v clone openosc
Cloning ssh://yonhan@pkgs.fedoraproject.org/rpms/openosc
Running: git clone ssh://yonhan@pkgs.fedoraproject.org/rpms/openosc --origin origin
Cloning into 'openosc'...
ssh: connect to host pkgs.fedoraproject.org port 22: Connection timed out
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 11, in <module>
    load_entry_point('fedpkg==1.37', 'console_scripts', 'fedpkg')()
  File "/usr/lib/python3.7/site-packages/fedpkg/__main__.py", line 86, in main
    sys.exit(client.args.command())
  File "/usr/lib/python3.7/site-packages/pyrpkg/cli.py", line 1931, in clone
    depth=self.args.depth)
  File "/usr/lib/python3.7/site-packages/pyrpkg/__init__.py", line 1543, in clone
    self._run_command(cmd, cwd=path)
  File "/usr/lib/python3.7/site-packages/pyrpkg/__init__.py", line 1228, in _run_command
    raise rpkgError('Failed to execute command.')
pyrpkg.errors.rpkgError: Failed to execute command.
[rtd@bxb-rtd-vm20 fedora-scm]$

But I can clone it anonymously. Then I saw "Could not execute import_srpm: Request is unauthorized." error when doing "fedpkg import" command.

[rtd@bxb-rtd-vm20 fedora-scm]$ fedpkg -v clone -a openosc
Cloning https://src.fedoraproject.org/rpms/openosc.git
Running: git clone https://src.fedoraproject.org/rpms/openosc.git --origin origin
Cloning into 'openosc'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Git-excludes patterns were added into /home/rtd/fedora-scm/openosc/.git/info/exclude
[rtd@bxb-rtd-vm20 fedora-scm]$ cd openosc/
[rtd@bxb-rtd-vm20 openosc]$ fedpkg import  ~/yonhan/fedora-review-dir/openosc-1.0.2-1.fc33.src.rpm 
Could not execute import_srpm: Request is unauthorized.
[rtd@bxb-rtd-vm20 openosc]$ ls -al
total 492
drwxrwxr-x. 3 rtd rtd   4096 Jul  7 14:45 .
drwxrwxr-x. 3 rtd rtd   4096 Jul  7 14:44 ..
drwxrwxr-x. 8 rtd rtd   4096 Jul  7 14:45 .git
-rw-rw-r--. 1 rtd rtd      0 Jul  7 14:45 .gitignore
-rw-rw-r--. 1 rtd rtd 482329 Jul  7 14:45 openosc-1.0.2.tar.gz
-rw-rw-r--. 1 rtd rtd   1793 Jul  7 14:45 openosc.spec
-rw-rw-r--. 1 rtd rtd     30 Jul  7 14:44 README.md
-rw-rw-r--. 1 rtd rtd      0 Jul  7 14:45 sources
[rtd@bxb-rtd-vm20 openosc]$ 


Should I continue to proceed with:

   git commit -sm "Initial import (#1812961)"
   fedpkg push


Let me know how to proceed.

Thanks,
Yongkui

Comment 37 Robert-André Mauchin 🐧 2020-07-07 20:39:45 UTC
Should I continue to proceed with:

   git commit -sm "Initial import (#1812961)"
   fedpkg push


No do not continue if the archive is not uploaded to dist-git.

> Could not execute import_srpm: Request is unauthorized.

Have you identified with kinit first?

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Install_the_developer_client_tools
and
https://fedoraproject.org/wiki/Infrastructure/Kerberos

i.e. before being allowed to upload something you need to identify yourself to Koji with Kerberos:

env KRB5_TRACE=/dev/stdout kinit yonhan@FEDORAPROJECT.ORG

Then type your FAS username password.

Comment 38 yonhan 2020-07-07 23:57:29 UTC
hi Robert-Andre,

Thanks for the suggestions!

After re-running kinit, I successfully uploaded the tarball.

[rtd@bxb-rtd-vm20 openosc]$ kinit yonhan@FEDORAPROJECT.ORG
Password for yonhan@FEDORAPROJECT.ORG: 
[rtd@bxb-rtd-vm20 openosc]$ 
[rtd@bxb-rtd-vm20 openosc]$ fedpkg import  ~/yonhan/fedora-review-dir/openosc-1.0.2-1.fc33.src.rpm
Uploading: /home/rtd/fedora-scm/openosc/openosc-1.0.2.tar.gz
######################################################################## 100.0%
diff --git a/.gitignore b/.gitignore

index 0000000..5bcb111
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (openosc-1.0.2.tar.gz) = 56b3d2a6f7f4b01937717c80a07b0bdcc874c8093c9ce69b5420846cbc18cb7d57cad42864e8e4526a9b7b48680fafc4873c44579987888abbaa2d774b668e5f
--------------------------------------------
New content staged and new sources uploaded.
Commit if happy or revert with: 'git reset --hard HEAD' (warning: it reverts also eventual user changes).

[rtd@bxb-rtd-vm20 openosc]$ git commit -sm "Initial import (#1812961)"
[master b0424bd] Initial import (#1812961)
 3 files changed, 78 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 openosc.spec
 create mode 100644 sources
[rtd@bxb-rtd-vm20 openosc]$ 
[rtd@bxb-rtd-vm20 openosc]$ fedpkg push
Please visit https://id.fedoraproject.org/openidc/Authorization?scope=openid+https%3A%2F%2Fid.fedoraproject.org%2Fscope%2Fgroups+https%3A%2F%2Fmbs.fedoraproject.org%2Foidc%2Fsubmit-build+https%3A%2F%2Fsrc.fedoraproject.org%2Fpush&response_type=code&client_id=fedpkg&redirect_uri=http%3A%2F%2Flocalhost%3A12345%2F&response_mode=query to grant authorization

but I could not connect the above https://id.fedoraproject.org/openidc/Authorization? link. I always run into the below error when connecting with a web-browser.

Unable to connect

Firefox can’t establish a connection to the server at localhost:12345.

Comment 40 Robert-André Mauchin 🐧 2020-07-08 12:35:21 UTC
[rtd@bxb-rtd-vm20 openosc]$ fedpkg push
Please visit https://id.fedoraproject.org/openidc/Authorization?scope=openid+https%3A%2F%2Fid.fedoraproject.org%2Fscope%2Fgroups+https%3A%2F%2Fmbs.fedoraproject.org%2Foidc%2Fsubmit-build+https%3A%2F%2Fsrc.fedoraproject.org%2Fpush&response_type=code&client_id=fedpkg&redirect_uri=http%3A%2F%2Flocalhost%3A12345%2F&response_mode=query to grant authorization

but I could not connect the above https://id.fedoraproject.org/openidc/Authorization? link. I always run into the below error when connecting with a web-browser.


I never ever have gotten such message. Is this because you're not using SSH? I don't know how to help you. Try asking help on Fedora-devel mailing list.

Try following this doc for HTTP push: https://docs.pagure.org/pagure/usage/http_push.html

Create an API key at: https://src.fedoraproject.org/settings#nav-api-tab (full perm)

Edit ~/.config/rpkg/fedpkg.conf and add:

[fedpkg.distgit]
token = YOURAPIKEY

Then try pushing again.

Comment 41 yonhan 2020-07-08 16:44:38 UTC
hi Robert-Andre,

I tried to use HTTP push: https://docs.pagure.org/pagure/usage/http_push.html

Any user can generate API tokens with the commit ACL which reads in the UI as: Commit to a git repository via http(s).

but in my pagure.io user setting: https://src.fedoraproject.org/settings#nav-api-tab

I only see the following ACLS as candidates:

ACLs
 Create a new project (create_project)
 Fork a project (fork_project)
 Comment on a ticket (issue_comment)
 Create a new ticket (issue_create)
 Modify an existing project (modify_project)
 Comment on a pull-request (pull_request_comment)
 Open a new pull-request (pull_request_create)
 Flag a pull-request (pull_request_flag)
 Merge a pull-request (pull_request_merge)
  
Why I don't see the "Commit to a git repository via http(s)" ACL?

Comment 42 yonhan 2020-07-08 18:07:21 UTC
Also I am trying to connect to fedoraproject.org via SSH.

I have generated public key pairs via ssh-keygen, and uploaded my ~/.ssh/id_rsa.pub into my FAS account.

[rtd@bxb-rtd-vm20 fedora-scm]$ ssh -i ~/.ssh/id_rsa yonhan@fedoraproject.org
The authenticity of host 'fedoraproject.org (2604:1580:fe00:0:dead:beef:cafe:fed1)' can't be established.
RSA key fingerprint is SHA256:2GMEV/jRPneOKXFUrveDO0iwWhK9Dd5Ob1wQXUEWzoA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fedoraproject.org,2604:1580:fe00:0:dead:beef:cafe:fed1' (RSA) to the list of known hosts.
yonhan@fedoraproject.org: Permission denied (publickey).
[rtd@bxb-rtd-vm20 fedora-scm]$ 

I wonder why it says "Permission denied (publickey)".

Comment 43 yonhan 2020-07-08 18:13:32 UTC
oh, my bad. it should be fedorapeople.org, not fedoraproject.org. Now this ssh connection to fedorapeople.org issue is fixed.

Comment 44 yonhan 2020-07-08 19:21:56 UTC
I can connect to yonhan@fedorapeople.org via ssh successfully, but failed to connect to pkgs.fedoraproject.org via ssh:

[rtd@bxb-rtd-vm20 fedora-review-dir]$ ssh -vv yonhan@pkgs.fedoraproject.org
OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally pkgs.fedoraproject.org
debug2: match not found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally pkgs.fedoraproject.org
debug2: match found
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug2: resolving "pkgs.fedoraproject.org" port 22
debug2: ssh_connect_direct
debug1: Connecting to pkgs.fedoraproject.org [38.145.60.17] port 22.
debug1: connect to address 38.145.60.17 port 22: Connection timed out
ssh: connect to host pkgs.fedoraproject.org port 22: Connection timed out
[rtd@bxb-rtd-vm20 fedora-review-dir]$

Comment 45 yonhan 2020-07-08 20:01:39 UTC
One question:
If I access this URL: https://pagure.io/settings#nav-basic-tab

Then I can see the below items that I can configure:

User Settings
Profile
Email Addresses
API Keys
SSH Keys
Preferences
Force Logout

You can see that I have the "SSH Keys" tab as below URL, which actually displays my uploaded SSH key:
https://pagure.io/settings#nav-ssh-tab

However, if I access this below URL:
https://src.fedoraproject.org/settings#nav-basic-tab

Then I can only see the below items which do not contain "SSH Keys" tab:

User Settings
Profile
Email Addresses
API Keys
Preferences
Force Logout

Does this mean that the two accounts have not synchronized yet? 

From this URL https://src.fedoraproject.org/rpms/openosc, it says "You need to upload SSH key to be able to clone over SSH", which actually points to the https://src.fedoraproject.org/settings#nav-basic-tab URL.

Comment 46 yonhan 2020-07-09 14:49:57 UTC
I think I have narrowed down the root cause for my vm20 not working with "fedpkg clone ssh://". It must be due to firewall setting.

I have another VM which does not have this kind of strict firewall, and I uploaded my SSH id_rsa.pub key to fedora, and now I can successfully clone via SSH on this new VM:

git clone --verbose ssh://yonhan@pkgs.fedoraproject.org/rpms/openosc
Cloning into 'openosc'...
Enter passphrase for key '/users/yonhan/.ssh/id_rsa': 
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

However, this new VM is RedHat Linux 7.x version, which does not have fedpkg tool available. Can I just use git tool to do the push from this new RHEL7.x VM?

Comment 47 yonhan 2020-07-09 15:02:09 UTC
oh, I think I found the root cause. it is due to routing issue in my vm20.

debug2: resolving "pkgs.fedoraproject.org" port 22
debug2: ssh_connect_direct
debug1: Connecting to pkgs.fedoraproject.org [38.145.60.17] port 22.
debug1: connect to address 38.145.60.17 port 22: No route to host
ssh: connect to host pkgs.fedoraproject.org port 22: No route to host
[rtd@bxb-rtd-vm20 ~]$ 

you can see, it says "No route to host". Again this may be due to the strict firewall.

I run "traceroute pkgs.fedoraproject.org", and it displays different results from what I get from the new VM without firewall.

Comment 48 Robert-André Mauchin 🐧 2020-07-09 15:39:13 UTC
Sorry I can't help you much with this, I know nothing about networking stuff, try asking for help on the fedora-devel mailing list.

Comment 49 yonhan 2020-07-09 16:49:04 UTC
I discovered that on my vm20, I can ssh connect to IPv6 address without issue, however, if its IPv4 address, then it will fail.

fedorapeople.org has IPv6 address, therefore, I can ssh to it directly.
pkgs.fedoraproject.org has only IPv4 address, thus I cannot ssh to it.

the same issue for github.com URL, which has only IPv4 address.

but I don't know how to configure proxy or do anything to find a workaround for my "fedpkg clone openosc" issue.

so it seems that this ssh approach will not work for me, I will explore the https approach next, which seems to require a graphical session to work.

Comment 50 Mattia Verga 2020-07-09 19:05:20 UTC
Yonhan, the steps at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers should work.

I suggest you to start over from the beginning, delete your local directory where you cloned openosc repo, then follow these steps:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Fedora_Account
(pay attention to point 4 of this step, the RSA SSH key installed on your machine must match the key you uploaded into FAS. It may take an hour for the key to be propagate in Fedora infrastructure after you uploaded it into FAS, so just wait)

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Configure_Your_Git

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Install_the_developer_client_tools
('dnf install fedora-packager' and 'echo "yourfasid" > ~/.fedora.upn')

Setup kerberos or, as I do, just run 'kinit yourfasid@FEDORAPROJECT.ORG'

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Check_out_the_module

At this point, if 'fedpkg clone' fails it means there's still something wrong, do not just clone the repo anonymously...

Comment 51 Fedora Update System 2020-07-10 22:40:23 UTC
FEDORA-2020-5f1c91eb01 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f1c91eb01

Comment 52 yonhan 2020-07-10 22:45:55 UTC
hi Mattia, Robert-Andre,

Thank you very much for the instructions and guidance!

Today I switched to a new VM without the firewall restriction and successfully fedpkg-cloned the openosc via SSH. And all the instructions now work for me on this new VM.

I have pushed and built openosc for f33/f32/f31.

one quick question: I have run "fedpkg update --type newpackage --bugs 1812961" for the f31 branch.

Do I need to run "fedpkg update --type newpackage --bugs 1812961" for f32/f33 too?

Thanks,
Yongkui

Comment 53 Fedora Update System 2020-07-11 02:06:20 UTC
FEDORA-2020-5f1c91eb01 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-5f1c91eb01 \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f1c91eb01

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 54 Mattia Verga 2020-07-11 07:31:18 UTC
(In reply to yonhan from comment #52)
> hi Mattia, Robert-Andre,
> 
> Thank you very much for the instructions and guidance!
> 
> Today I switched to a new VM without the firewall restriction and
> successfully fedpkg-cloned the openosc via SSH. And all the instructions now
> work for me on this new VM.
> 
> I have pushed and built openosc for f33/f32/f31.
> 
> one quick question: I have run "fedpkg update --type newpackage --bugs
> 1812961" for the f31 branch.
> 
> Do I need to run "fedpkg update --type newpackage --bugs 1812961" for
> f32/f33 too?
> 
> Thanks,
> Yongkui

You don't need to create updates for Rawhide (which is now F33) because they're automatically created upon a successful build:
https://bodhi.fedoraproject.org/updates/?search=openosc&releases=__current__&releases=__pending__

But, you ALWAYS have to create updates starting from the higher Fedora version available, in your case you have created an update for F31 and you must create an update for F32 also to not break the "chain"...

Comment 55 Fedora Update System 2020-07-11 17:11:55 UTC
FEDORA-2020-3400d18f43 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3400d18f43

Comment 56 yonhan 2020-07-11 17:13:40 UTC
Hi Mattia,

Got it. I have run "fedpkg update --type newpackage --bugs 1812961" for f32.

Thank you very much for the quick response and explanation!

Yongkui

Comment 57 Fedora Update System 2020-07-12 01:47:22 UTC
FEDORA-2020-3400d18f43 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-3400d18f43 \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3400d18f43

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 58 Fedora Update System 2020-07-19 02:19:29 UTC
FEDORA-2020-5f1c91eb01 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 59 Fedora Update System 2020-07-20 01:22:50 UTC
FEDORA-2020-3400d18f43 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.