Re: convert everything to rpmautospec?

[Miroslav Lichvar]

On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote:
> -1 for existing packages certainly - none of my git commit logs
> are written with the expectation that they will double as package
> changelogs so doing so may break the changelog.

Yes, I think rpm changelog is for users of the package and git log
is for the maintainers. Most of the time the entries apply to both,
but sometimes they don't. I use a script to generate rpm changelog
entries from git log as a separate commit with the release bump, but
occasionally I need to edit the text.

-- 
Miroslav Lichvar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnsmasq default configuration changed

[Miroslav Lichvar]

On Mon, Jan 15, 2024 at 05:31:36PM +0100, Kevin Kofler via devel wrote:
> Petr Menšík wrote:
> > Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard
> > resolver does. You can use listen-address=127.0.0.53 if you like, but
> > then it will conflict with systemd-resolved.
> 
> You just wrote that you make it listen by default on all interfaces, and 
> then filter.

If I understand it correctly, it will do that only if the
configuration was modified (an additional interface was specified).
The default configuration should work exactly as before.

> This means it will conflict over the port 53.

They bind to different addresses by default.

-- 
Miroslav Lichvar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direwolf FTBFS: Need C help

[Miroslav Lichvar]

On Wed, Aug 02, 2023 at 06:47:58AM -0500, Richard Shaw wrote:
> I was poking around trying to fix the FTBFS problem with direwolf and it
> looks simple enough. As it has built before for years I assume it's related
> to GCC 13.
> 
> Here's the error:
> /builddir/build/BUILD/direwolf-1.6/src/direwolf.h:303:56: error: expected
> declaration specifiers or '...' before string constant
>   303 | #define strlcpy(dst,src,siz)
> strlcpy_debug(dst,src,siz,__FILE__,__func__,__LINE__)
>   |^~~~

I think this is the new glibc 2.38 support of strlcpy.

You need to modify direwolf.h to take the path of the other systems
#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__APPLE__)

e.g. by replacing it with #if 1

For an upstream patch it would be better to check for the
__GLIBC_PREREQ macro and __GLIBC_PREREQ(2, 38)), but the current glibc
header in rawhide still claims to be 2.37.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miroslav Lichvar]

On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote:
> * Other developers: Some packages need to change their spec files from
> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
> all packages switched in this way, but it is not required. Supporting
> optional tzdata installation for as many workloads as possible allows
> those workloads to minimize their container image size.
> List of packages which need to be changed:
> * glibc (glibc-common)

There are packages that rely on the glibc->glibc-common->tzdata
dependency. The one I know is chrony, which in the default
configuration needs the "right/UTC" timezone to get the TAI-UTC
offset. I suspect there are other packages that will need to add
Recommends or Requires.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: ppc64le builds taking ages

[Miroslav Lichvar]

On Sat, May 20, 2023 at 02:51:06PM -0700, Kevin Fenzi wrote:
> I've moved all the power9 virthosts running builders over to a 6.3.x
> kernel. 
> 
> Please let me know if this helps or doesn't with slowness issues. 

It seems the execution is still freezing occasionally. My recent build
of chrony failed on ppc in %check due to a test not being able to
start and connect within 10 seconds.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gnutls time_t breakage on i686 (was: Re: qemu on i686)

[Miroslav Lichvar]

On Thu, Mar 02, 2023 at 11:57:42AM +, Daniel P. Berrangé wrote:
> If any other Fedora maintainer looks after packages that use GNULIB,
> then it is quite likely that they also need to add --disable-year2038
> to their specfiles to avoid i686 brokenness when talking to any
> non-glibc libraries that use time_t, or exposing a library using time_t

There are about 150 packages that provide "bundled(gnulib)". About 50
have "lib" in their name. Just wondering, wouldn't it be less work to
enable 64-bit time_t in the rpm CFLAGS, rebuild everything, and deal
with a potentially smaller number of broken packages with the benefit
of fixing Y2038?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libgps soname bump (gpsd-3.25)

[Miroslav Lichvar]

libgps from the gpsd package had another ABI break. The following
packages need to be rebuilt:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking
xtide

All packages rebuilt correctly for me locally, except vfrnav which
seems to have some broken dependencies due to new texlive.

The new gpsd package has been built in f38-build-side-61789.

Could a proven packager please rebuild the packages in this side tag?

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Linking problem with ncurses on rawhide, not f37

[Miroslav Lichvar]

On Mon, Jan 02, 2023 at 06:07:25PM +0100, Florian Weimer wrote:
> * Miroslav Lichvar:
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wmove@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `derwin@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wenclose@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> > `_nc_panelhook_sp@NCURSES6_5.8.20110226'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wcursyncup@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `copywin@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `newpad@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> > `wnoutrefresh@NCURSES6_5.0.19991023'
> > ...
> >
> > libform and libpanel depend on libncurses.
> 
> Could you give them a similar treatment, with more linker scripts?

It doesn't work if I add AS_NEEDED(libpanel libform) to libncurses. It
works if I add it to libtinfo. I guess that comes from the order of
NEEDED in liblldb.so.13git, which is included in the linker command.

  NEEDED   libtinfo.so.6
  NEEDED   libncurses.so.6
  NEEDED   libform.so.6
  NEEDED   libpanel.so.6

Would every ncurses library need to have all other libraries in
AS_NEEDED?

In any case, I don't like much the fact that with this approach it
would be possible to link ncurses/panel/form applications using just
-lncurses or -ltinfo. An application developed on Fedora might fail to
build on other systems.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Linking problem with ncurses on rawhide, not f37

[Miroslav Lichvar]

On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote:
> It may work to use this for libtinfo.so:
> 
> GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED 
> (/usr/lib64/ncurses-novs/libncurses.so.6))

FWIW, I tried this and the error messages from the swift-lang build
changed from:

/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`tparm@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_name_match@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`wtimeout@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_doalloc@NCURSES6_TINFO_5.0.19991023'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_safe_strcat@NCURSES6_TINFO_5.2.20001021'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`baudrate_sp@NCURSES6_TINFO_5.8.20110226'
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to 
`_nc_update_screensize@NCURSES6_TINFO_5.0.19991023'
...

to 

/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wmove@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`derwin@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wenclose@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
`_nc_panelhook_sp@NCURSES6_5.8.20110226'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`wcursyncup@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`copywin@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
`newpad@NCURSES6_5.0.19991023'
/usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
`wnoutrefresh@NCURSES6_5.0.19991023'
...

libform and libpanel depend on libncurses.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Linking problem with ncurses on rawhide, not f37

[Miroslav Lichvar]

On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote:
> Miroslav, we may have to revert the versioning change if the AS_NEEDED
> approach does not work.

Ok, I reverted that change, at least until I have more time for
testing the possible fixes.

>   Linking versioned libncurses against
> unversioned libtinfo etc. would solve this, but I don't know how it
> would to get to this point.

I don't know much about ELF. Is it possible to remove versions from
specific symbols in the symbol table after the libraries are built,
maybe with some tool like chrpath?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libFLAC soname bump

[Miroslav Lichvar]

On Wed, Sep 14, 2022 at 06:09:16PM -0500, Michel Alexandre Salim wrote:
> > I tried to rebuild them all except chromium which I suspect would take
> > too much space and time. Only ardour6, audacity, and xmms2 failed, for
> > unrelated reasons.
> > 
> All the packages on your list except the 4 you listed in the paragraph
> above should be built now, please check if anything is missing:
> 
> https://koji.fedoraproject.org/koji/builds?inherited=0=58420=-build_id=1

Thanks! It looks good to me.

I see that Mamoru rebuilt the three packages that failed for me
locally and also vlfrx-tools which I missed somehow. The only missing
package now seems to be chromium, which failed to build after last
update and it takes almost whole day to build, so I think we'll leave
that to its maintainer.

I submitted an update for the side tag:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-918429c97a

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libFLAC soname bump

[Miroslav Lichvar]

On Mon, Sep 12, 2022 at 12:24:34PM -0500, Maxwell G via devel wrote:
> On Mon Sep 12, 2022 at 11:29 AM CDT, Michel Alexandre Salim wrote:
> > > 
> > > Would a proven packager be willing to take care of it? The new flac is
> > > now built in --target=f38-build-side-58420. libsndfile and audiofile
> > > need to be rebuilt next as some of the other packages depend on them.
> > > 
> >
> > Sure, what do you need done? Just push an update from that sidetag, or
> > actually do some rebuilds as well?
> 
> It sounds like they need all of those packages to be rebuilt:

Yes, I'm looking for a proven packager to rebuild the packages and
submit an update for those that built successfully. Otherwise, we
would need to ask the individual maintainers and that would likely
take a long time to finish this.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libFLAC soname bump

[Miroslav Lichvar]

flac-1.4.0 changes the libFLAC and libFLAC++ sonames. There are also
some incompatible changes in the API, but I didn't see any packages
failing to built due to these changes.

The following packages need to be rebuilt:

libsndfile
audiofile
SDL_sound
SFML
allegro5
ardour6
audacious-plugins
audacity
audiocd-kio
bigloo
butt
chromium
easytag
flac123
getdata
gstreamer1-plugins-good
gtkpod
k3b
kf5-audiocd-kio
kid3
kwave
libextractor
libfishsound
libopenmpt
mame
mednafen
mkvtoolnix
mp3fs
ocp
opus-tools
qmmp
retroarch
scummvm
scummvm-tools
sox
squeezelite
timidity++
traverso
vavoom
vorbis-tools
xmms2

I tried to rebuild them all except chromium which I suspect would take
too much space and time. Only ardour6, audacity, and xmms2 failed, for
unrelated reasons.

Would a proven packager be willing to take care of it? The new flac is
now built in --target=f38-build-side-58420. libsndfile and audiofile
need to be rebuilt next as some of the other packages depend on them.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Suggestion: Bring back ncurses-compat-libs

[Miroslav Lichvar]

On Mon, Aug 22, 2022 at 10:27:30AM +0200, LuK1337 wrote:
> Hello,
> 
> I recently updated to prerelease F37 and to my surprise I noticed
> that ncurses-compat-libs has been removed in this change:
> https://src.fedoraproject.org/rpms/ncurses/c/e9317e9.

This compat package was enabled 7 years ago. Do we have some
guidelines whether applications outside of Fedora should be
considered, or how long generally it is expected for a compat package
to be available?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild is very slow with large files

[Miroslav Lichvar]

On Tue, Jul 12, 2022 at 09:26:14AM +0200, Florian Weimer wrote:
> * Marius Schwarz:
> > and I don't think, this tasks needs to read the clock that often too.
> 
> strace shouldn't see a system call here because clock_gettime should be
> handled in the vDSO.  This suggests something is wrong with the system
> (unless it's some obscure variant that really doesn't have vDSO support).

It doesn't necessarily have to be something wrong with the system.
The vDSO clock_gettime() works only with specific clocksources,
typically TSC on x86_64. On some older HW it's not reliable enough to
be selected by the kernel, or it could be a VM which doesn't have one
that would work with migrations, etc.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Miroslav Lichvar]

On Thu, Jun 02, 2022 at 05:46:05PM +0200, Petr Pisar wrote:
> $ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
> $ ./a.out
> sizeof(time_t)=8
> 
> I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
> proposed solution would require rebuilding in the same way all libraries which
> tar uses and which pass time_t and similar types in their interface. That
> would probably break other packages.

Now that the kernel and glibc have this feature, would it make sense
to change the global CFLAGS to build everything with 64-bit time_t on
all currently supported 32-bit archs? If not now, how close to the
32-bit overflow in 2038?

It's not just about keeping current time and file timestamps. There
are applications/libraries that calculate future dates and overflows
can lead to serious issues.

Switching to 64-bit time_t may require some patching, e.g. when the
code assumes sizeof(long) == sizeof(time_t).

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 37: Add kernel parameters that help prevent local exploits

[Miroslav Lichvar]

On Thu, May 19, 2022 at 03:15:16AM -, Hellosway Here via devel wrote:
> Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on 
> randomize_kstack_offset=on vsyscall=none ` as default kernel command line 
> arguments. This can help prevent local exploits by making it harder to 
> exploit the kernel. I do not think there will be any breakage, I have been 
> using these for a long time. The performance impact is minimal, a few of 
> these can improve performance. 

I don't know much about the other options, but vsyscalls=off can have
a significant impact on performance of applications that frequently
read the system clock. The whole point of that feature is performance.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

libgps soname bump (gpsd-3.24)

[Miroslav Lichvar]

libgps from the gpsd package had an API and ABI break. As usual, the
following packages need to be rebuilt:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking

I tried to rebuild them locally. It seems only direwolf needs a new
patch. The direwolf-gpsapi12 patch needs to be replaced with
https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi14.patch

The new gpsd package has been built in f37-build-side-53409.

Could a proven packager please replace the patch and rebuild the
dependant packages in this side tag?

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Miroslav Lichvar]

On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote:
> Took git years to migrate from SHA-1, and some others haven't even started.

git is a good example showing that this won't be easy. The SHA-256
object format is still marked as experimental and not the default.

Is there a plan to migrate the Fedora repositories?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libgps soname bump (gpsd-3.23)

[Miroslav Lichvar]

On Wed, Aug 11, 2021 at 08:27:27PM +0200, Björn 'besser82' Esser wrote:
> All packages have been rebuilt successfully, except for vfrnav, which
> fails for a segfault in inkscape during the testsuite.
> 
> Both sidetags can be merged now, as vfrnav hasn't been built
> successfully for a longer period of time, including the recent mass-
> rebuild for fc35.

I've submitted updates for both sidetags.

Thanks!

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

libgps soname bump (gpsd-3.23)

[Miroslav Lichvar]

libgps provided by the gpsd package had another API and ABI break. The
following packages need to be rebuilt:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking

I tried to rebuild them locally and it seems only direwolf needs a
patch. It's here:
https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch

The new gpsd package is built in a rawhide and f35 sidetag.
Please build your packages with:

fedpkg build --target=f36-build-side-44504
fedpkg build --target=f35-build-side-44506

If a proven packager is willing to take care all of the packages,
please let us know.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Miroslav Lichvar]

On Wed, May 19, 2021 at 09:34:16AM +0100, Daniel P. Berrangé wrote:
> FWIW, there's also debian:stable-slim at 72 MB
> 
> > registry.opensuse.org/opensuse/leaplatest   1a798c6c690f  5
> > days ago108 MB
> > docker.io/library/ubuntu   latest   7e0aa2d69a15  3
> > weeks ago   75.1 MB
> 
> So we need to cull 45 MB / 36% of 'fedora-minimal' to reach this target,
> or 112 MB / 60% of 'fedora'.

I suspect that is going to be difficult. It seems the biggest single
application there is microdnf and it's huge dependencies, like glib2.
Maybe linking it statically would help, but we don't want to go there,
right?

At what point this stops being Fedora? It already uses a different
implementation of the package manager.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: "Fedora Linux" in /etc/os-release

[Miroslav Lichvar]

On Tue, Mar 09, 2021 at 10:19:53PM -0500, Neal Gompa wrote:
> Fedora actually *has* other things branded Fedora today, and may do so
> for more things in the future. They don't have the opportunity to get
> attention because our ability to present ourselves beyond the Linux
> distribution sucks.
> 
> > Overall, ust. no. Deliberately breaking every ansible, chef, or
> > other deployment tools that check /etc/os-release for a consistent
> > operating system reference name is not a benefit to anyone.
> 
> Ansible uses ID and VERSION_ID, which are not changing, so this will
> have no impact there.

No, ansible uses NAME from /etc/os-release. ID is used only from
/usr/lib/os-release. See

https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/distribution.py#L390

But /etc/redhat-release seems to be preferred over /etc/os-release, so
I guess this change won't have an impact on the "distribution"
variable.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

libgps soname bump (gpsd-3.22)

[Miroslav Lichvar]

libgps provided by the gpsd package had another API/ABI break. The
following packages are impacted:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking

From those, only vfrnav and foxtrotgps seem to need a patch to build
successfully with the new gpsd. The patches are available here:

https://bazaar.launchpad.net/~foxtrotgps-team/foxtrotgps/trunk/revision/327
https://gitlab.com/tsailer/vfrnav/-/merge_requests/5.patch

I've built the new gpsd in the side tag f34-build-side-35797. Please
rebuild your packages there. If a proven packager could take care of
all the packages, that would be appreciated.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NTP change (was Re: Schedule for Wednesday's FESCo Meeting (2021-01-06))

[Miroslav Lichvar]

On Wed, Jan 06, 2021 at 07:40:07AM -0600, Chris Adams wrote:
> Once upon a time, Miroslav Lichvar  said:
> > If the bumps were due to insufficient documentation (e.g. the
> > ntp-refclock man page), would you have any suggestions on how to
> > improve it, or submit a patch?
> 
> Since I'm using a refclock that doesn't handle PPS, I have chronyd
> configured to use /dev/pps0.  In that case, the example systemd unit in
> the ntp-refclock man page can't work, because chronyd expects /dev/pps0
> to exist when it starts (or it'll just exit).  The ordering has to be
> PPS setup, then chronyd, then ntp-refclock.

I see. That could be a third example (using the PALISADE driver) in
the man page.

> It would be nicer if ntp-refclock just included the systemd unit and
> used a config to get the options (e.g. /etc/sysconfig/ntp-refclock), and
> maybe even the PPS setup unit.  Obviously the udev rules are device
> specific, but it might be good to include an example in the docs
> directory.

Good idea. Added to my todo list.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NTP change (was Re: Schedule for Wednesday's FESCo Meeting (2021-01-06))

[Miroslav Lichvar]

On Tue, Jan 05, 2021 at 08:30:39AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > #2517 F34 Change: ntp replacement
> > https://pagure.io/fesco/issue/2517
> > APPROVED (+5, 0, 0)
>
> I changed my stratum 1 server from ntpd to chronyd+ntp-refclock... had a
> few small bumps to figure out (getting the NTP, PPS, and chrony services
> correct), but it is working.

If the bumps were due to insufficient documentation (e.g. the
ntp-refclock man page), would you have any suggestions on how to
improve it, or submit a patch?

> It might be useful for others to document how I have it working - where
> would be a good place for that?  Submit a README example or something?

Is it meant to be a description of an alternative to switching to
ntpsec wrt to the ntp retirement? Fedora-specific information can be
included in the package's documentation, but I'm not sure how many
people will look for that. Generally applicable information would be
best upstream.

If you didn't use gpsd because you hit a bug there, it would be nice
to send a bugreport upstream. A debug output (-D 9 option) might be
enough to get it fixed.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Mon, Dec 07, 2020 at 10:47:31AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Since the plan it to Obsolete the old package, I think you should trigger
> on the removal of it:
> %triggerun ntp <= ... 
> 
> # copy service enablement from the old name to the new name
> if systemctl is-enabled -q ntpd 2>/dev/null; then
>   systemctl enable ntpsecd # if the name is different...
> fi

More magic is needed. The service name is the same (ntpd). The ntpsec
post disables the service before the triggerun runs. I suspect the
original state needs to be captured first in a triggerprein or pre
scriptlet.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Fri, Dec 04, 2020 at 01:38:02AM +0100, Björn Persson wrote:
> > == Upgrade/compatibility impact ==
> > 
> > The `ntp` package is replaced automatically on upgrade to Fedora 34.
> > The configuration file ''/etc/ntp.conf'' is saved as to
> > ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
> > ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
> > fall back to the default configuration in ''/etc/ntp.d'' using the
> > ''pool.ntp.org'' servers.
> > 
> > The `ntpd` service is disabled after the upgrade and needs to be enabled 
> > again.
> 
> That's not so nice to those users who can use NTPsec as a drop-in
> replacement. For them it would be better to keep the configuration file
> and have the service enabled if it was enabled before the upgrade.

Good point. What would be the best way to do that in the ntpsec
package? Trigger on ntp?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Wed, Dec 02, 2020 at 09:29:05AM -0600, Chris Adams wrote:
> Once upon a time, Tomasz Torcz  said:
> >   There ARE functional changes. Mainly removal of long-obsolete drivers,
> > full list can be found at:
> > https://docs.ntpsec.org/latest/ntpsec.html#incompatible
> > https://www.ntpsec.org/removal-plan.html
> 
> Yeah, this would break my use of NTP, since I use one of the drivers to
> be removed (I have an old Trimble Resolution T, which uses the Palisade
> driver).  I think I tried gpsd with it at one point and something didn't
> work, can't remember now.

The ntp drivers stay in the ntp-refclock package. It requires an extra
service to run the ntpd driver, but you can feed the ntpsec ntpd or
chrony using the SHM or SOCK driver.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Wed, Dec 02, 2020 at 10:00:04AM -0500, Neal Gompa wrote:
> Makes sense, though I think the release notes section would be pretty
> easy to write:
> 
> "The classic ntpd service was formerly provided by the ntp package.
> The ntp software has significant security issues and development seems
> moribund. It has now been replaced with the ntpsec package, an
> actively maintained fork of the ntp software. No functional changes
> are expected."

Thanks. I put it there with "No functional changes are expected for most
users" as ntpsec doesn't have some of the less useful features of ntp.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring ntp

[Miroslav Lichvar]

On Mon, Nov 02, 2020 at 09:52:59PM +, Gary Buhrmaster wrote:
> On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia  wrote:
> 
> > So, use "chrony" instead?
> 
> For some use cases, there is also the option of
> systemd-timesyncd as a ntp client.

timesyncd is a very minimal NTP client. It can be recommended in some
specific use cases, like a local network with a trusted server, but
not in the most common case of a client using random public servers on
Internet. There are other minimal clients that should be considered
before timesyncd, e.g. openntpd or the busybox ntpd.

> > and can the ntp.conf files be ported gracefully to a
> > compatible chrony.conf setting?

In the vast majority of cases, yes, it can. There is even a ntp2chrony
script for automatic conversion.

The most common thing that people seem to miss is the mode-6 protocol,
which is needed by some monitoring tools. That won't be supported in
chrony, but it is in ntpsec.

Autokey has been superseded by NTS.

Broadcast/multicast modes are better supported by PTP (linuxptp).

> If you are using hardware to discipline your server
> using one/more of the hardware specific drivers
> things get more complicated.

Reference clocks shouldn't be a big issue. The refclock drivers from
ntp will stay in Fedora, at least for now, in the ntp-refclock
package. In future it might need to be switched to the ntpsec drivers.
For GPS receivers, which are by far the most common reference clocks,
there is also gpsd.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring ntp

[Miroslav Lichvar]

On Mon, Nov 02, 2020 at 06:09:18PM +0100, Björn Persson wrote:
> Miroslav Lichvar wrote:
> > The main problem is that they don't fix all known security issues. In
> > the CVE list I see about 10 issues that were not fixed at all or only
> > partially, some exploitable in default configuration.
> 
> That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.

There is no official list. You would need to inspect the code to see
what have been actually fixed. For some CVEs they only provided
mitigations and in some cases the fixes were wrong or incomplete.
You can look for my comments in the upstream bugzilla.

The list of 10 issues that I think are not (fully) fixed yet follows.
Probably not complete or completely accurate, but if you need details
about a specific issue, I can check the code.

CVE-2013-5211
CVE-2015-7705
CVE-2015-7974
CVE-2015-7979
CVE-2015-8139
CVE-2016-1548
CVE-2016-4955
CVE-2016-7426
CVE-2018-7170
CVE-2020-13817

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring ntp

[Miroslav Lichvar]

On Mon, Nov 02, 2020 at 04:09:33PM +0100, Reindl Harald (privat) wrote:
> Am 02.11.20 um 15:33 schrieb Miroslav Lichvar:
> > In Fedora, there seems to be only one package that has a dependency on
> > ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
> > problematic mode-6 protocol. It should work with ntpsec.
> > 
> > Thoughts?
> 
> only as long there is a fully compatible drop-in replacement with proper
> provides/obsoletes
> 
> in other words the config below needs to work because ESXi hosts and cetral
> servers on other locations are using two of this ntpd instances to provide
> time for the other machines in the network over vpn and/or for virtualized
> guests by vmware-tools timesync

Your config doesn't use any special features. Just a plain client and
server. You can switch easily to chrony or ntpsec.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring ntp

[Miroslav Lichvar]

On Mon, Nov 02, 2020 at 10:14:05AM -0500, Steven A. Falco wrote:
> I use ntp heavily for multiple stratum 1 timeservers here.  If you drop ntp, 
> I will have to build my own from source.  Not a big problem, but I'd 
> personally like to see ntp stay available in Fedora.

I have few stratum-1 servers too, but I'm not running ntp.

What reference clock do you have? Unless it's something very rare, you
shouldn't need ntp for that. GPS receivers are well supported by gpsd
and ntpsec kept most of the ntpd drivers for hardware that is still
widely used.

There is also the ntp-refclock package which contains all ntpd drivers
with a thin wrapper that allows them to be used with chrony, ntpsec,
or basically any NTP server.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Retiring ntp

[Miroslav Lichvar]

I think we should consider retiring the ntp package. The upstream
project is not in a good shape and it doesn't seem to be improving.
Contributors left long time ago. The development is slow and happens
behind closed doors. They still use bitkeeper.

The main problem is that they don't fix all known security issues. In
the CVE list I see about 10 issues that were not fixed at all or only
partially, some exploitable in default configuration. This was one of
the reasons why we dropped it from RHEL.

I'm not sure how many users of ntp are there. As a replacement, we
could package ntpsec. It is an actively maintained fork of ntp which
has removed a lot of code and fixed or avoided most of the issues in
ntp. What I don't like much about it is that they kept the mode-6
protocol of NTP, which allows traffic amplification and is still
causing problems on Internet, but I think the code and the project are
definitely in a better shape than ntp. I can help with the packaging
or review, and as a comaintainer if there is a volunteer for the
role of the primary maintainer.

In Fedora, there seems to be only one package that has a dependency on
ntp: nagios-plugins-ntp-perl. It's a monitoring plugin using the
problematic mode-6 protocol. It should work with ntpsec.

Thoughts?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: packages still requiring ncurses

[Miroslav Lichvar]

On Tue, Sep 29, 2020 at 12:43:14PM +0200, Petr Pisar wrote:
> The built-in path is: /etc/termcap, /usr/share/misc/termcap. But none of these
> directories exist in Fedora. ncurses-base has /usr/share/terminfo. My
> knowledge about termcap and terminfo is zero, but it seems that
> /usr/share/terminfo files are binary files, while perl-Term-Cap expects
> a plain text files. Maybe that's the difference between termcap and terminfo.

termcap is an obsolete format of terminal descriptions, which has some
major limitions. Long time ago, Fedora shipped a termcap translated
from the ncurses terminfo database, but everything should be using
terminfo now.

> And thus the hard dependency on ncurses is correct. At the end Term::Cap
> documentation defines the Perl module as "a Perl termcap interface". Not as a
> terminfo interface.

Makes sense to me.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Miroslav Lichvar]

On Tue, Aug 04, 2020 at 06:26:37PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
> > That's possible (the paths could be hardcoded in the systemd unit
> > file), but is it a good idea to force the users to use the new system?
> > If someone has a modified config, or is using one of the many ansible
> > roles for configuring NTP for example, why should it stop working? We
> > don't have to break configuration tools that just generate a config
> > from scratch.
> 
> Backwards compatiblity should be kept obviously. In systemd we look at
> {/usr,/usr/local,/etc,/run}/foo.conf and
> {/usr,/usr/local,/etc,/run}/foo.conf.d/*.conf, so foo.conf is the main
> config file, while the "drop-ins" in /etc/ have higher priority and
> server as overrides. This is backwards compatible with having just
> /etc/foo.conf.

I don't see how that works. If I hardcoded the paths and split
/etc/foo.conf into several /usr/lib/foo.conf.d/*.conf fragments, or
any other package dropped a file in that directory, there would be
additional settings applied from those fragments even if the user
had an old /etc/foo.conf file, right? The user would need to figure
out what are those additional settings and revert them in /etc. That
would not be a great experience.

If the fragments were explicitly loaded from the new default
/etc/foo.conf, it would be obvious to a user merging the
configuration, and it wouldn't change anything for users keeping their
old config not loading the fragments.

Also, dropping /etc/foo.conf from the package would cause rpm to
rename it to .rpmsave, which would need to be worked around in a
scriptlet I guess.

> > The trouble is that a fragment having a different name cannot disable
> > servers specified in a different fragment. If anaconda wanted to
> > override the default servers, it would need to know the name of the
> > fragment. In some cases users/vendors/products may want to specify
> > additional servers, sometimes replace them.
> 
> This can be handled by having a directive that means "wipe previous
> config for this setting". In systemd we handle this by treating an
> empty assignment as special:
> SystemCallFilter=open
> SystemCallFilter=
> SystemCallFilter=write
> SystemCallFilter=read close
> is equivalent to SystemCallFilter=write read close.

That looks hackish to me. We would need new directives to remove
previous settings in chrony. I thought the point of splitting the
default configuration was to get logical groups of settings that can
be overriden by adding a file to /etc/chrony.d, replacing a group of
related settings at once, which will work even when a newer package
adds more settings there. If I need to override individually each
directive from the default configuration, which I cannot predict for
future packages, then I don't see much of a point in this.

systemd doesn't seem to have fragmented configs. Maybe dovecot is a
better example. It has configuration split like this:

/etc/dovecot/conf.d/10-auth.conf
/etc/dovecot/conf.d/10-director.conf
/etc/dovecot/conf.d/10-logging.conf
/etc/dovecot/conf.d/10-mail.conf
/etc/dovecot/conf.d/10-master.conf
/etc/dovecot/conf.d/10-ssl.conf
/etc/dovecot/conf.d/15-lda.conf
/etc/dovecot/conf.d/15-mailboxes.conf
/etc/dovecot/conf.d/20-imap.conf
/etc/dovecot/conf.d/20-lmtp.conf
/etc/dovecot/conf.d/20-pop3.conf
/etc/dovecot/conf.d/20-submission.conf
/etc/dovecot/conf.d/90-acl.conf
/etc/dovecot/conf.d/90-plugin.conf
/etc/dovecot/conf.d/90-quota.conf

I was thinking about doing something similar for chrony, but move that
to /usr/lib. Maybe I'm mixing different incompatible ideas.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Miroslav Lichvar]

On Tue, Aug 04, 2020 at 04:32:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> It's nice to not require any files in /etc (so for example the admin
> can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
> using /etc/chrony.conf to load other files, please consider just
> building this logic directly into the code. There is also no need to
> make those config paths configurable.

That's possible (the paths could be hardcoded in the systemd unit
file), but is it a good idea to force the users to use the new system?
If someone has a modified config, or is using one of the many ansible
roles for configuring NTP for example, why should it stop working? We
don't have to break configuration tools that just generate a config
from scratch.

> > My concern is that it will basically break all existing tools that
> > need to check and/or modify the configuration (e.g. anaconda). They
> > will need to know the naming of the files which have specific settings
> > in order to override them, or implement a parser duplicating the
> > chronyd logic to figure out which files are loaded from where.
> 
> The whole goal of the config-in-dropin-files-logic is that anaconda
> wouldn't parse existing config, it would just write
> /etc/chrony.d/50-anaconda.conf that would override only the parts it
> cares about.

The trouble is that a fragment having a different name cannot disable
servers specified in a different fragment. If anaconda wanted to
override the default servers, it would need to know the name of the
fragment. In some cases users/vendors/products may want to specify
additional servers, sometimes replace them.

> Also, please don't invent a new logic — just follow the same one that
> systemd does [1]. This has the advantage that if something *needs* to
> look all of config, it can reuse what an existing loader. Also, admins
> don't need to learn a new set of rules. Ideally,
> 'systemd-analyze cat-config chrony.conf' would just work.

I was following the liboverdrop logic, which probably adopted the
systemd convention. For printing the whole configuration there is now
a "chronyd -p" command. The systemd cat-config command seems to expect
the ini-style syntax. That's not going to work here.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Switching package to fragmented default configuration

[Miroslav Lichvar]

I'm considering to split the default configuration file in the chrony
package to make it easier for vendors, products, and configuration
tools to override some specific settings (like the default NTP
servers) by dropping a file into a directory, instead of having to
modify a packaged config file. It seems to be a modern trend, used
by many packages in Fedora, and I have received some RFEs to adopt
in chrony.

The default /etc/chrony.conf would just have a single directive
loading configuration fragments from /etc/chrony.d and
/var/lib/chrony.d (and maybe also /var/run/chrony.d).

My concern is that it will basically break all existing tools that
need to check and/or modify the configuration (e.g. anaconda). They
will need to know the naming of the files which have specific settings
in order to override them, or implement a parser duplicating the
chronyd logic to figure out which files are loaded from where. Also,
I'm not sure how user-friendly this is for regular users who modify
the configuration manually.

Are there any recommendations for switching an existing single-config
package to a fully fragmented configuration? Is it worth the trouble,
or do you have any other suggestions?

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Miroslav Lichvar]

On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
> Hi All,
> 
> 
> I just noticed that a lot my packages got a FTBFS because of
> failing to build on s390x. The first set of rebuilds failed with:
> 
> "BuildrootError: Requested repo (1785390) is DELETED"

I have one of those too, but oddly enough another package of mine is
failing (only) on s390x in its test suite (using LD_PRELOAD as
mentioned in the previous thread - but that wasn't specific to s390x,
right?).

It would be nice if there was an up-to-date rawhide s390x available to
all Fedora packagers for quick debug sessions, where I don't need root
or anything special, and it can be safely shared with others.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libgps soname bump (gpsd-3.20)

[Miroslav Lichvar]

A new version of gpsd is ready to be build in rawhide. This is a
second attempt. It now bumps the libgps soname. Per repoquery the
following packages have a dependency on libgps and will need a
rebuild:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
qlandkartegt
vfrnav
viking

Some packages already carry a patch for the new libgps API. Some will
need to be fixed. I've uploaded the patches here:

https://mlichvar.fedorapeople.org/tmp/gpsd

vfrnav doesn't build for me due to a C++ issue, so I'm not sure if the
gps fix is complete.

If a proven packager could add/merge the patches and rebuild all
the packages, please me know. Otherwise, I'll rebuild gpsd sometimes
next week and let the maintainers fix their packages.

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Miroslav Lichvar]

On Mon, May 04, 2020 at 04:44:00PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Aside: the PEERNTP option seems to be very weakly documented. After
> some searching I found [1, 2] and [3]. Some up-to-date documentation would
> be necessary if users are expected to configure this.

Ok. I filed bug #1831542 to improve the documentation.

> It sounds like PEERNTP should be a per-interface setting. If I'm
> connecting to a trusted network or VPN, I might want to use and trust
> the provided NTP servers. If connecting to a public network, don't trust
> and use NTS to verify servers.

You could do that. PEERNTP can be set for each interface in the
corresponding /etc/sysconfig/network-scripts/ifcfg-* file.

However, as was suggested earlier in the thread, there will likely be
a new upstream option in chrony to globally control mixing of
unauthenticated and authenticated NTP sources, so PEERNTP doesn't have
to be disabled when all NTP servers from DHCP are not to be trusted,
e.g. because they are not expected to authenticate their upstream
servers.

> Also, what software supports /etc/sysconfig/network? I think we currently
> have initscripts-network, NetworkManager, systemd-networkd in Fedora.

It works with the initscripts and NetworkManager. For systemd-networkd
there is no dispatcher mechanism in Fedora, so NTP servers provided by
DHCP are ignored when using systemd-networkd with chrony or ntp. In
Debian and Ubuntu there is a networkd-dispatcher service for that.

> > An option could be added to disable the time checks before the
> > first update of the clock. This would have an impact on security.
> 
> ... how would that look? It'd need support in chrony itself, right?
> Would upstream accept such code?

Yes. It's already supported upstream and in our latest rawhide
package. The time checks can be disabled with the NoCertTimeCheck
directive in chrony.conf. The idea is that anaconda will set it when
no RTC is found or it has no battery backup (if can we detect that).

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Miroslav Lichvar]

On Thu, Apr 09, 2020 at 02:08:46PM -0500, Brandon Nielsen wrote:
> Additionally, the 'nts' option for 'server' and 'pool' directives, to me,
> does not make it immediately clear that NTS will be required for _all_ NTP
> servers. To me, that option implies that NTS will be enforced for that
> particular pool or server. Especially since I can have additional directives
> without that option set (which admittedly makes little sense).

Yes, the nts option is specific to the source. Sometimes it makes
sense to mix non-NTS and NTS sources (e.g. in the case with trusted
network), but probably more commonly it does not.

> Finally, the suggestion of bootstrapping NTP without using NTS when TLS
> checks fail concerns me. It needs to be clear when such a thing is allowed
> or not.

The suggestion was to disable the TLS time check, not TLS+NTS
completely.

> I would be much happier with some kind of `requireents` option in
> `/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no plain
> NTP servers will be used (from DHCP or otherwise), NTP bootstrapping
> mentioned above would also be forbidden. When not set, NTS is still verified
> for cases where the option is set, but other NTP servers still work
> (bootstrapping allowed?).

Good idea. An upstream option to control mixing of authenticated and
non-authenticated sources would make sense to me. This would nicely
minimize downstream-specific changes. I think it might have more than
just two settings (enabled, disabled) and we'll need to figure out
where exactly it should be controlled (e.g. configuration,
measurements, or source selection).

Thanks,

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: system time in Fedora 32

[Miroslav Lichvar]

On Mon, Apr 13, 2020 at 12:47:58PM -0500, Dennis Gilmore wrote:
> [root@localhost ~]# hwclock --hctosys --verbose
...
> hwclock: settimeofday() failed: Invalid argument

> I came across https://www.mail-archive.com/info-gnu@gnu.org/msg02694.html
> which to me indicates that the API used by hwclock is being removed
> and it needs updating. I wanted to get a better understanding of what
> is going on, and if it should be considered as a blocker for f32.

Filing a bug for hwclock (util-linux) makes sense, but I don't think
it's a blocker as hwclock is normally not used for setting the system
clock or RTC. That's the job of the kernel. There is an issue with the
system->RTC part being unreliable.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Miroslav Lichvar]

On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote:
> On 4/8/20 3:42 AM, Miroslav Lichvar wrote:
> > What is the issue with using untrusted DNS servers here? An NTS client
> > is supposed to verify the certificates. Local MITM attackers shouldn't
> > be able to force the client to synchronize to a different NTP server.
> > (Of course, they can always disable the synchronization.)
> > 
> 
> I'm not saying there is necessarily an issue, just a logical inconsistency.
> If the DNS servers provided by DHCP are trusted, why would any plain NTP
> servers also provided by DHCP not be trusted? I can do nefarious things with
> either.

I think it depends on the network. Is it yours or is it a random hotspot?

In general neither should be trusted, but most applications don't rely
on DNS being secure, so using random untrusted DNS servers from DHCP
is usually not a major issue. I'm ignoring privacy issues.

> Generally speaking, on a network I admin, if I've configured DHCP to provide
> things like NTP and DNS servers, it's because I intend client devices to use
> those things. While some devices choose to ignore DHCP provided DNS (and
> NTP), I can still reroute those requests at the edge router. Is that also
> possible with NTS? Even if it gets rerouted to a plain NTP server?

No, an NTS-enabled client cannot be redirected to a different server
(using a different certificate or NTS keys). That would be a security
issue. It's similar to DNS over HTTPS.

> I feel like if this is on by default we're basically saying nobody trusts
> any provided NTP server unless it supports NTS. If that's the case, do away
> with the 'trusted network' verbiage and just say that only NTS servers
> provided over DHCP will be used.

The NTP option in DHCP doesn't provide the client with a name of the
server (at least in IPv4), so it couldn't try NTS even if it wanted.

> Additionally, what about the no-internet case? Will a local, non-NTS NTP
> server be acceptable in that case? I feel like that would be handled by the
> change to PEERNTP you mention above. But then can't attackers "disable the
> synchronization" as you mention above, essentially forcing us back to no
> additional security?

I think the installer could verify that NTS works (which implies
working Internet connection) and if not, it would leave PEERNTP
enabled.

> > It would still work, even if we didn't use it by default. The name is
> > just an alias for pool.ntp.org. The servers used in the current
> > default configuration are not run by Fedora.
> > 
> 
> Does the alias provide no additional functionality? Does it help with an
> estimate of running Fedora machines in the wild?

The alias is a "vendor" zone to give the pool admins some control in
case our NTP clients create too much traffic and need to be stopped.
I think the admins have some statistics on DNS traffic in specific
zones, but I'm not privy to the data.

> Will there be some kind of 'canary domain' like there is for DoH
> (use-application-dns.net)?

I don't think I saw any suggestions for implementing that.

> Again from a network admin standpoint, if I
> provide a local NTP server without NTS, I want an easy way to tell the
> devices I manage to use it.

The PEERNTP option will still work. It may just have a different
default and/or have a new setting.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Network Time Security

[Miroslav Lichvar]

On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote:
> It doesn't make much sense to me for this to default to on if we still
> "trust" the DNS servers provided over DHCP.

What is the issue with using untrusted DNS servers here? An NTS client
is supposed to verify the certificates. Local MITM attackers shouldn't
be able to force the client to synchronize to a different NTP server.
(Of course, they can always disable the synchronization.)

> Additionally, it's not clear to
> me from the proposal what it would take for an NTP server provided over DHCP
> to be "trusted", or what a "trusted network" is. Are only NTS-enabled
> sources to be trusted?

Generally, yes.

What I meant, if someone for example had at home a stratum 1 server
(e.g. synchronized to GPS) and they trusted everything and everyone in
their local network, it would make sense to still use the server
(without NTS) in addition to any external time servers authenticated
by NTS.

The question is if we need to change the default value of the PEERNTP
option. There could be a new default which adds the servers provided
by DHCP only if chronyd is not using any servers with enabled
authentication.

> What becomes of the old default fedora.pool.ntp.org?

It would still work, even if we didn't use it by default. The name is
just an alias for pool.ntp.org. The servers used in the current
default configuration are not run by Fedora.

> Finally, from a purely personal standpoint, I don't like seeing yet more
> infrastructure being handed over to a hyperscaler like Cloudflare (see also
> DoH in Firefox). I would be less opposed to this being default if
> pool.ntp.org found a way to support it.

Yes, that's a valid point, which we need to consider. I don't have a
strong opinion either way.

I'd like to see pool.ntp.org to support NTS. But I'm not sure if the
trust of not being attacked will be comparable to a single entity
running the servers, even if the pool has a sufficient number of
NTS-enabled servers and implements some mitigations like mixing
servers from different countries.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Miroslav Lichvar]

On Mon, Aug 05, 2019 at 09:36:47AM -0700, Andrew Lutomirski wrote:
> On Mon, Aug 5, 2019 at 8:22 AM Andrew Lutomirski  wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
> >
> > Depending on the resolution of that bug, I suggest that Fedora
> > consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> > options.  IMO Fedora's default RPM build options should not cause
> > crashes on valid, if less-than-stylistically-great, code.  I don't
> > think that package maintainers should need to update package source to
> > use C++ in a more polite way.
> 
> And the bug has spoken.  v[v.size()] is undefined behavior.  Don't do it!

Ok, but does that mean the program has to abort? Could gcc do anything
dangerous here? If we were actually trying to catch undefined behavior
(e.g. with -fsanitize=undefined), I suspect Fedora wouldn't even boot
without a crash.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libgps soname bump (gpsd-3.19)

[Miroslav Lichvar]

A new version of gpsd was released. It breaks the ABI and API of
libgps again. If there are no objections, I'll build the package in
the next few days.

The incompatibilities are minor (reordered struct, removed redundant
field) and I don't expect it to affect most of the client
applications. Patching should be straightforward in any case. Please
let me know if there are any issues.

The following packages will need a rebuild:

collectd-5.8.1-6.fc31
direwolf-1.5-1.fc30
foxtrotgps-1.2.1-6.fc31
gpsdrive-2.11-51.fc31
marble-19.04.2-1.fc31
plasma-workspace-5.16.2-1.fc31
qlandkartegt-1.8.1-19.fc30
vfrnav-20190212-1.fc30
viking-1.7-2.fc30

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30: System-Wide Change proposal: DNF UUID

[Miroslav Lichvar]

On Tue, Jan 08, 2019 at 09:43:01AM +0100, Lennart Poettering wrote:
> Moreover, afair we install and enable NTP clients by default on all
> our installations, no? just like pretty much any other OS these days
> does... counting by NTP mostly just means switching from NTP pool
> servers to fedora's own servers.

I think it would be difficult/expensive to provide the same quality of
service as the pool with thousands of servers distributed around the
globe.

Switching completely would probably be a bad idea. A better approach
would be to configure the clients to use a mix of the pool servers and
our servers. I think that's what Ubuntu does.

> > 3. Logging NTP does not cover the problem the UUID is trying to help
> > solve.. there are two places where we undercount and overcount
> > systems.
> >  a. systems behind nat firewalls all show up as 1 ip address. ntp or
> > yum or gnome-hotspot ask multiple times during a day.. but not a set
> > number. Just looking at my 3 home systems I see around 1 to 80
> > connections depending on what i have done that day.
> 
> The amount of traffic within a time window is linear to the number of
> hosts behind that IP address. It's relatively easy to estimate that
> there are 5 clients behind an IP adress if you get 5 NTP request
> datagrams within one protocol iteration instead of just one...

That would work if the "tracking" NTP server was configured with a
fixed polling interval and disabled bursts, and the systems were always
running. In our default configuration we use a variable polling
interval and bursts. Tracking individual clients behind one IP address
is possible if their number is not very large, but it's a bit more
complicated (it depends also on the client's implementation), and it
can count only systems that are running at the same time.

> > 4. NTP is a high security problem when you concentrate it to a set of
> > servers. These become servers that everyone wants to hack even more
> > than build systems. These problems range from DDOS to active hacks.
> 
> Uh, well, the major NTP servers tend to be pretty well tested and
> fuzzed these days, and they can be sandboxed efficiently, since they
> involve no big stack but only trivial SOCK_DGRAM traffic. I see no
> reason whatsoever for them to be less secure than a hand-written HTTP
> service that only Fedora runs and doesn't get all the validation love
> the NTP servers get...

The problem are DoS attacks. If the number of servers was small, it'd
be easy (cheap) to take them all out. The pool has thousands of
servers. The weak point is rather in their monitoring.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libgps soname bump

[Miroslav Lichvar]

There is a new release of gpsd, which breaks the ABI and API of
libgps. If there are no objections, I'll build the package on Monday.

Most of the changes in the API seem to be extensions, but there is an
incompatible change in gps_read(). It has two new arguments. A
gps_read(x) call should be equivalent to gps_read(x, NULL, 0) in the
new version.

The following packages will need to be rebuilt (and probably also
patched):

collectd-gps-0:5.8.0-16.fc29
direwolf-0:1.5-0.1.beta4.fc30
foxtrotgps-0:1.2.1-1.fc29
gpsd-devel-0:3.17-5.fc29
gpsdrive-0:2.11-47.fc29
marble-widget-qt5-1:18.08.1-1.fc30
plasma-workspace-geolocation-0:5.13.90-1.fc30
qlandkartegt-0:1.8.1-17.fc29
qtgpsc-0:0.3.1-22.fc29
vfrnav-0:20180129-4.fc29
viking-0:1.6.2-7.fc29
xtide-0:2.15.1-6.fc29

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mlichvar pushed to lrzsz (master). "add man page symlinks for sb, sx, rb, rx programs (#1611501)"

[Miroslav Lichvar]

On Wed, Sep 12, 2018 at 01:47:00PM +0200, Tomasz Kłoczko wrote:
> > From 20e576638ca6bbc6583bb357353a6c66760fe457 Mon Sep 17 00:00:00 2001
> > From: Miroslav Lichvar 
> > Date: Sep 12 2018 11:00:41 +
> > Subject: add man page symlinks for sb, sx, rb, rx programs (#1611501)
> > +for m in rb rx; do ln -s rz.1 %{buildroot}%{_mandir}/man1/$m.1; done
> > +for m in sb sx; do ln -s sz.1 %{buildroot}%{_mandir}/man1/$m.1; done
> > +
> >  %find_lang %{name}
> >
> 
> Just FTR: This kind of modifications are wrong.
> After compressing {rs}z.1 in %post it will be {rs}z.1.gz and created
> symlinks will be pointing nowhere.

That may have been true in the past, but the current compression script seems
to fix the symlinks as expected.

$ rpm -qlvp lrzsz-0.12.20-46.fc30.x86_64.rpm | grep man1
lrwxrwxrwx1 rootroot7 Sep 12 13:05 
/usr/share/man/man1/rb.1.gz -> rz.1.gz
lrwxrwxrwx1 rootroot7 Sep 12 13:05 
/usr/share/man/man1/rx.1.gz -> rz.1.gz
-rw-r--r--1 rootroot 5810 Sep 12 13:05 
/usr/share/man/man1/rz.1.gz
lrwxrwxrwx1 rootroot7 Sep 12 13:05 
/usr/share/man/man1/sb.1.gz -> sz.1.gz
lrwxrwxrwx1 rootroot7 Sep 12 13:05 
/usr/share/man/man1/sx.1.gz -> sz.1.gz
-rw-r--r--1 root    root         7383 Sep 12 13:05 
/usr/share/man/man1/sz.1.gz

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libidn soname bump

[Miroslav Lichvar]

The libidn upstream has released 1.35, which increments the soname.
I'm planning to update the package on the next Tuesday.

The following packages will need to be rebuilt. I don't see anything
critical that should break the buildroot. Please let me know if that's
not the case.

certmonger-0.79.5-7.fc29
cone-0.96.2-3.fc28
echoping-6.1-0.7.beta.r434svn.fc28
eiskaltdcpp-2.2.11-13.20180207git6ca065b.fc29
freeDiameter-1.2.0-13.fc28
ghostscript-9.23-2.fc29   
gloox-1.0.14-5.fc27
hesiod-3.2.1-11.fc29
hydra-8.6-6.fc28
iris-1.0.0-0.32.20170212git8c2c9cb.fc28
jabberd-2.6.1-8.fc28
jreen-1.2.1-10.fc28
kopete-18.04.0-2.fc29
libgsasl-1.8.0-12.fc28
loudmouth-1.5.3-4.fc27
mcabber-1.1.0-1.fc29
monotone-1.1-25.fc28
perdition-2.1-7.fc26
perl-Net-LibIDN-0.12-29.fc28
pidgin-2.13.0-1.fc29
podofo-0.9.5-7.fc28
prosody-0.10.0-2.fc28
psi-plus-1.0-0.6.20170612git9.fc28
python-slixmpp-1.3.0-5.fc29
rubygem-idn-0.0.2-24.fc28
skipfish-2.10-0.16.b.fc28
swift-3.0-0.12.rc2.fc27
tgif-4.2.5-15.fc28
vacuum-im-1.3.0-0.8.20180214git01910e9.fc29

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ABI break in libidn-1.34

[Miroslav Lichvar]

On Fri, May 04, 2018 at 01:44:01PM +0200, Miroslav Lichvar wrote:
> There was an unexpected change in the ABI of libidn-1.34, which broke
> stringprep (bugs #1566414 #1573961).
> 
> I've built libidn packages for F27 and F28 which revert the change
> that broke the compatibility. In F28 there seems to be only one
> package (mcabber) which was built with libidn-1.34-1. It will probably
> need to be rebuilt with libidn-1.34-2. In F27 I don't see any packages
> built with libidn-1.34-1.

My repoquery was bad. There are more packages in F27/F28 that may need
to be rebuilt with the fixed libidn:

finch-2.13.0-1.fc27
libpurple-2.13.0-1.fc27
mcabber-1.1.0-1.fc27
pidgin-2.13.0-1.fc27

finch-2.13.0-1.fc28
libgs-9.23-2.fc28
libpurple-2.13.0-1.fc28
pidgin-2.13.0-1.fc28
mcabber-1.1.0-1.fc28

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ABI break in libidn-1.34

[Miroslav Lichvar]

There was an unexpected change in the ABI of libidn-1.34, which broke
stringprep (bugs #1566414 #1573961).

I've built libidn packages for F27 and F28 which revert the change
that broke the compatibility. In F28 there seems to be only one
package (mcabber) which was built with libidn-1.34-1. It will probably
need to be rebuilt with libidn-1.34-2. In F27 I don't see any packages
built with libidn-1.34-1.

In rawhide the number of packages built with libidn-1.34-1 is larger.
I've asked the upstream to release a new version with a fixed soname.
Should we just wait for that and then rebuild all packages? Or apply
the F27/28 fix and rebuild the packages built with libidn-1.34-1, or
rebuild packages that were not built with libidn-1.34-1 yet without
applying the F27/28 fix?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: broken terminfo database in latest ncurses?

[Miroslav Lichvar]

On Thu, Feb 01, 2018 at 10:50:59AM +0100, Miroslav Lichvar wrote:
> It seems to be an slang issue, not supporting the new format. There
> was a report on the ncurses list:
> http://lists.gnu.org/archive/html/bug-ncurses/2018-01/msg00052.html
> 
> I'm not sure how difficult it will be to fix/update slang. We could
> revert the changes in terminfo if necessary.

It looks like a support for the extended numerical capabilities is
already included in the slang repo...

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: broken terminfo database in latest ncurses?

[Miroslav Lichvar]

On Thu, Feb 01, 2018 at 04:48:50AM +, Tomasz Kłoczko wrote:
> Hi,
> 
> Just applied all recent updates and seems after this now mc is not able
> recognize correctly number of available colors on gnome-terminal and xterm,
> and on gnome-terminal cursors are not working now.

It seems to be an slang issue, not supporting the new format. There
was a report on the ncurses list:
http://lists.gnu.org/archive/html/bug-ncurses/2018-01/msg00052.html

I'm not sure how difficult it will be to fix/update slang. We could
revert the changes in terminfo if necessary.

For mc there is also an option to switch to ncurses. Has anyone tried
it recently?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Removing ldconfig scriptlets

[Miroslav Lichvar]

On Tue, Jan 30, 2018 at 10:04:48AM +0100, Igor Gnatenko wrote:
> For those who didn't check Change page since today's morning: Thanks to Jason
> Tibbits (tibbs) who proposed %ldconfig_scriptlets macro and its
> implementation. 
> 
> Now we have 4 macros you could use: %ldconfig, %ldconfig_post,
> %ldconfig_postun, %ldconfig_scriptlets.

The macros should be used instead of this conditional from the change
page?

%if (0%{?rhel} && 0%{?rhel} <= 7) || (0%{?fedora} && 0%{?fedora} <= %27)

Which package is supposed to provide the macros? I don't see them in
an up-to-date F27 (and neither rawhide) buildroot.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal to remove NetworkManager from Core group

[Miroslav Lichvar]

On Fri, Jan 19, 2018 at 11:48:52AM +0100, Thomas Haller wrote:
> When you say "Core" group, what are the practical effects of removing
> it? You can uninstall NetworkManager on Fedora today. Do you mean, it
> should not be installed by default? But you need a way to connect to
> the network on a newly installed system, if only to download networkd.
> Would you then install networkd by default?

The trouble is that systemd-networkd and other components of systemd
which are currently not used by default are always installed. It's all
in the systemd package. If it was split into subpackages and installed
services could be easily deduplicated, maybe people would have a
different opinion on what should be or not be installed by default.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: git package history lost?

[Miroslav Lichvar]

On Thu, Nov 16, 2017 at 09:14:53AM +0100, Nikos Mavrogiannopoulos wrote:
> However, going to the repo for f27 at:
> https://src.fedoraproject.org/rpms/crypto-policies/blob/f27/f/crypto-policies.spec#_102
> 
> That message is no longer there.
> 
> Commit history has also no mentioning of that date.
> https://src.fedoraproject.org/rpms/crypto-policies/commits/f27
> 
> It seems that this particular commit has disappeared from git history
> in src.fedoraproject.org. Have others noticed something similar, or
> could it be that messed something up?

The message seems to be in the master branch
https://src.fedoraproject.org/rpms/crypto-policies/blob/master/f/crypto-policies.spec#_110

Maybe the build happened around that time when the f27 branch was
created and it didn't pick up the latest commit?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libgps soname bump (gpsd-3.17)

[Miroslav Lichvar]

I'm planning to build gpsd-3.17 in rawhide the next week. It bumps the
soname of libgps. It seems the API was just extended, so I don't
expect any problems with rebuilding the client applications.

If my repoquery command was correct, the following packages will need
to be rebuilt:

collectd-5.7.2-12.fc27
foxtrotgps-1.2.0-7.fc27
gpsdrive-2.11-42.fc27
marble-17.08.1-1.fc28
plasma-workspace-5.10.5-3.fc28
qlandkartegt-1.8.1-13.fc27
qtgpsc-0.3.1-17.fc26
vfrnav-20160429-10.fc28
viking-1.6.2-5.fc27
xtide-2.15.1-3.fc27.1

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: switching libcurl back to OpenSSL and providing the libcurl-minimal subpackage

[Miroslav Lichvar]

On Wed, Apr 05, 2017 at 03:52:22PM +0200, Kamil Dudka wrote:
> In order to make even smaller Fedora base images, it was proposed to switch
> libcurl back to OpenSSL.  The Fedora Crypto Consolidation project, which
> motivated the switch of libcurl from OpenSSL to NSS ten years ago, is now
> deprecated and libcurl is the only package that pulls NSS as its dependency
> into the Fedora base image.  Hence, by switching libcurl back to OpenSSL, we
> could create Fedora base image that contains fewer crypto libraries inside.

I'm just wondering, does this change anything from the security point
of view? Has history shown one library to be better than the other,
for instance in the number of important issues found in the TLS
implementation?

Also, wasn't there an issue with the OpenSSL's licensing and GPL?
If it still is, could it affect any of the packages that are now using
libcurl?

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Miroslav Lichvar]

On Wed, Dec 14, 2016 at 10:08:33AM +0100, Florian Weimer wrote:
> > The original RFCs for IPv6 mandated support for IPsec, but that's no
> > longer required as of RFC 6434.  Nothing else popped out at me as
> > necessary for IPv6, but it's probably a moot point given XFRM.
> 
> IPv6 people argue that it's required to sort addresses according to the
> length of the overlap with configured subnets and local addresses.  This
> requires that you enumerate the local network interfaces and their
> addresses, and this information is only available over Netlink for IPv6.
> IPv4 has an ioctl, too, but not IPv6.

FWIW, some programs use /proc/net/if_inet6 to get local IPv6
addresses. I'm not sure if it contains all information needed for this
case.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Miroslav Lichvar]

On Wed, Jun 01, 2016 at 04:09:19PM +0100, Howard Chu wrote:
> Matthias Clasen wrote:
> > I am very much in favor of systemd enforcing that the session actually
> > ends when I log out, so that I don't accidentally leave processes
> > running. Leaking session processes have been a perennial problem that
> > we have been battling forever (gconf, ibus, pulseaudio, the list goes
> > on...). And they are causing actual problems, from preventing re-login
> > to subtly breaking the next session to slowing down shutdown.
> 
> So far you have only identified problems associated with GUI sessions. I
> still see no justification for terminating *all* user processes when it's
> clear there's only a problem with one very specific class of processes, all
> being launched in a very specific context.

Yeah, to me it sounds like these problematic processes should say
"kill me when the session ends", rather than others having to opt-out.

If the processes are killed by default, won't other applications start
to rely on it and users who change the default will have more and more
applications running after logout?

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ntpstat

[Miroslav Lichvar]

On Fri, Feb 12, 2016 at 08:48:41AM -0500, Przemek Klosowski wrote:
> On 02/12/2016 06:10 AM, Miroslav Lichvar wrote:
> >It has been included in the ntp package for a very long time, but it's
> >not actually part of the upstream ntp package (and can't be as it's
> >licensed under GPL). I guess ntpstat should rather have its own
> >package.
> Since you are thinking of rewriting, it would make sense to offer it to
> upstream. Do you think they'd take it?

That's a good point. I'll ask them. I think they wouldn't be
interested in the part of the script that adds chrony support, so it
would continue as an ntpd only utility.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ntpstat

[Miroslav Lichvar]

ntpstat is a small utility included in the ntp package, which prints
the synchronization status of ntpd, the maximum error of the clock and
few other fields. Apparently, there are people who find it useful for
monitoring.

It has been included in the ntp package for a very long time, but it's
not actually part of the upstream ntp package (and can't be as it's
licensed under GPL). I guess ntpstat should rather have its own
package.

There are few issues with it, however. The last ntpstat release is
from 2002 and there is no upstream now. We have a couple of patches
that make it work with the current ntp code. It implements the mode 6
protocol (used by ntpq for instance), but it's really the minimum
needed to send a request and parse the data if it happens to be in the
first packet of the response. It can break easily. Also, it doesn't
support IPv6, to get an IPv6 address for the system peer it would have
to iterate over the NTP associations.

Instead of fixing and maitaining the C code, I thought it would be
much easier to rewrite it from scratch as a bash script using ntpq.
Also, it would be easy to add support for chronyd using the chronyc
utility. This is what I have now, its output should be in most cases
identical to what the original ntpstat produced.

https://raw.githubusercontent.com/mlichvar/ntpstat/master/ntpstat

I could write a new man page and put it in the ntp package as a
replacement. Or it could be added as a new package in Fedora, which
ntp could recommend or suggest. Would that make sense? Another option
is to simply drop ntpstat from ntp with no replacement.

Thoughts?

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ntpstat

[Miroslav Lichvar]

On Fri, Feb 12, 2016 at 12:36:16PM +0100, Peter Lemenkov wrote:
> 2016-02-12 12:10 GMT+01:00 Miroslav Lichvar <mlich...@redhat.com>:
> 
> > I could write a new man page and put it in the ntp package as a
> > replacement. Or it could be added as a new package in Fedora, which
> > ntp could recommend or suggest. Would that make sense? Another option
> > is to simply drop ntpstat from ntp with no replacement.
> >
> > Thoughts?
> 
> I'd simply remove it. Otherwise you have to act as upstream for this
> outdated thing.

FWIW, I'd have no problem with maintaining a hundred-line shell
script. I think it would rarely need an update. Of course, if there
were no users for it, then I'd rather drop it.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fwd: Use suid_dumpable=2 for development releases

[Miroslav Lichvar]

On Fri, Feb 12, 2016 at 12:40:37PM +, Tom Hughes wrote:
> On 12/02/16 12:24, Jakub Filak wrote:
> >I believe that maintainers of packages like chrony will be really delighted
> >with this change, while will not weaken security of Fedora for regular users.
> 
> What part of chrony is setuid? I don't see an suid bit on any of it's
> executables... Nor any file capabilities which is the other thing the manual
> page says triggers this.

The chrony files don't have any set*id bits set, but the chronyd
process, like many other daemons, calls setuid()/setgid() in order to
drop root privileges. The proc(5) man page lists that as a reason
for not producing a coredump.

I was wondering what security implications would setting suid_dumpable
to 2 by default had and why it needs to be restricted to development.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

dialog soname bump

[Miroslav Lichvar]

The dialog package was updated to 1.3 in rawhide, which changed the
soname of the library to libdialog.so.13. Nothing else beside dialog
seems to be using the library or buildrequire the devel subpackage, so
no rebuilds should be needed and I'm not really sure why I'm sending
this email.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos wrote:
> As Florian suggested it makes more sense to compartmentalize chrony so
> that only a small controlled part of it needs to run with seccomp. My
> recommendation, if you want to use libraries in the filtered code, make
> their authors aware of that, so that they document any changes in the
> used system calls, and if possible ask them to document the existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )

chronyd doesn't use libc for much more than that. There is memory
allocation, reading/writing system clock, reading/writing/moving
files, creating/connecting/binding sockets, receiving/sending
packets, and select(). Name resolving is now out of the filter. The
only other library that's currently used after the seccomp filter is
loaded is freebl3 from NSS.

I guess some of that could be moved to the helper process. If only the
most dangerous code (whatever that is) should run with seccomp, I'm
not sure if there is a layer where a clean small cut could be made. I
suspect the interface between the two processes would be huge and it
would bloat the code significantly.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos wrote:
> As Florian suggested it makes more sense to compartmentalize chrony so
> that only a small controlled part of it needs to run with seccomp. My
> recommendation, if you want to use libraries in the filtered code, make
> their authors aware of that, so that they document any changes in the
> used system calls, and if possible ask them to document the existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )

chronyd doesn't use libc for much more than that. There is memory
allocation, reading/writing system clock, reading/writing/moving
files, creating/connecting/binding sockets, receiving/sending
packets, and select(). Name resolving is now out of the filter. The
only other library that's currently used after the seccomp filter is
loaded is freebl3 from NSS.

I guess some of that could be moved to the helper process. If only the
most dangerous code (whatever that is) should run with seccomp, I'm
not sure if there is a layer where a clean small cut could be made. I
suspect the interface between the two processes would be huge and it
would bloat the code significantly.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fw: the-new-hotness saw an update for eiciel, but pkgdb says the maintainers are not interested in bugs being filed

[Miroslav Lichvar]

On Fri, Jan 15, 2016 at 06:00:48PM +0100, Michael Schwendt wrote:
> Anyone knows what this cryptic message is trying to tell?
> What kind of "update" does it refer to?
> Is this a belated notification about 0.9.11 which is in koji
> since Dec 2015 already?
> 
> [...]
> 
> the-new-hotness saw an update for eiciel, but pkgdb says the maintainers are 
> not interested in bugs being filed
>   https://release-monitoring.org/project/8847/

It seems this happens when a new project is added to the release
monitoring site and it finds the first release (that may already be in
Fedora). Not sure if it's intentional.

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Tue, Oct 06, 2015 at 10:15:38AM +0200, Florian Weimer wrote:
> On 10/05/2015 05:27 PM, Miroslav Lichvar wrote:
> > I guess glibc and getaddrinfo() will be the most problematic part in
> > the chrony seccomp support. Is there a precedent in Fedora of a
> > package using a seccomp filter and getaddrinfo() by default?
> 
> getaddrinfo uses NSS under the cover, which loads NSS modules and runs
> their code to perform lookups.  The system configuration may even use
> modules which do not come with the distribution.
> 
> You need to run getaddrinfo from a separate process/thread which lacks a
> seccomp filter.

FWIW, the latest upstream code now does name resolving in a separate
process as you have suggested. Since the original post I already had
to add some system calls that were apparently made with some NSS
configurations. Hopefully it will be more reliable now. The COPR has a
build of the current code if anyone is interested in testing.

Thanks,

-- 
Miroslav Lichvar
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Wed, Oct 07, 2015 at 09:24:22AM +0200, Dan Horák wrote:
> On Mon, 5 Oct 2015 13:58:26 +0200
> Miroslav Lichvar <mlich...@redhat.com> wrote:
> 
> > In chrony 2.2-pre1 was added support for system call filtering with
> > the kernel seccomp facility. In chrony it's mainly useful to reduce
> > the damage from attackers who can execute arbitrary code, e.g. prevent
> > gaining the root privileges through a kernel vulnerability.
> 
> please keep in mind that libseccomp currently supports only limited set
> of architectures -
> http://pkgs.fedoraproject.org/cgit/libseccomp.git/tree/libseccomp.spec#n5
> It will change (in Rawhide) after mainline kernel 4.3 release when s390
> and ppc will become supported as well.

The chrony spec should now follow that. Thanks.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Testing chrony seccomp support

[Miroslav Lichvar]

In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.

The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.

I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.

If you would like to help with the testing:

1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running

If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.

For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/

Thanks,

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testing chrony seccomp support

[Miroslav Lichvar]

On Mon, Oct 05, 2015 at 08:23:05AM -0500, Michael Catanzaro wrote:
> (Also fun is to try making the same list of filters work across
> distros.)

And across supported architectures. So far, I tested it only on x86_64
and i686 and there were quite a few differences. I would be surprised
if it worked on arm even in the default configuration :).

> So chrony might work perfectly now, but who knows how broken it will be
> after a couple months of updates Well, you'll find out after
> testing it in rawhide. Hope seccomp works better for you than it did
> for me. Of course, for programs with few dependencies, there's not
> really much problem.

I guess glibc and getaddrinfo() will be the most problematic part in
the chrony seccomp support. Is there a precedent in Fedora of a
package using a seccomp filter and getaddrinfo() by default?

If we can't enable it by default, I'll be ok with that. Currently I'm
just interested in how it works for others.

Another possibility is to add a new level to the chrony seccomp
support that would use a blacklisting approach, disabling syscalls or
their arguments that historically are most dangerous and we can be
sure won't be ever needed. I hope that's not an empty set.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ncurses update to 6.0

[Miroslav Lichvar]

On Fri, Aug 21, 2015 at 12:18:15PM +0100, Tom Hughes wrote:
 According to http://www.gnu.org/software/ncurses/ the new ABI should include
 symbol versioning, which would hopefully avoid the need for a repeat of this
 pain in the future, but as far as I can see none of the symbols in the
 current F23 build are versioned?

The new ncurses libs are in rawhide only. The symbol versioning is
disabled by default and it's not enabled it in our spec. Enabling it
is easy, but if we wanted to disable it later, it would require
immediate rebuild of all ncurses applications, so I'd like to be sure
it is a good idea before doing so.

I'm not sure if it would be possible to use symbol versioning for
compatibility when there are changes in definition of structures like
cchar_t, as there are between ABI 5 and ABI 6. I think the upstream
intention is to use it to mark new symbols, not compatibility.

Hiding private symbols is definitely useful, but with the versioning
itself I think there could be some drawbacks, e.g. binaries built on
distros using the versioning won't run on distros not using it.

Also, the number of different versions the symbols use seems to be
quite large, so there could be an increase in the rpmdb and yum repo
sizes. I guess that's not really a problem.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ncurses update to 6.0

[Miroslav Lichvar]

On Tue, Aug 18, 2015 at 11:38:08PM +0100, Richard W.M. Jones wrote:
 guestfish uses APIs from readline and libtinfo directly.  It does not
 use ncurses APIs directly.

 So it is overlinked, but IIRC that's because you had to use
 `-lreadline -lncurses' to make readline work properly on some old
 systems.

Yeah, that was needed to allow the applications to make a choice
between libtermcap and libncurses.

 Can we replace that with `-lreadline'?
 
 Are there any implications for a program which actually uses
 termcap/libtinfo functions also?

If guestfish does need the terminfo functions, I think it should be
linked with libtinfo or libncurses (on systems where libtinfo is not
separated from libncurses).

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ncurses update to 6.0

[Miroslav Lichvar]

On Tue, Aug 04, 2015 at 12:33:42PM +0200, Miroslav Lichvar wrote:
 As for updating the ncurses package, my current plan is to build the
 libs in both ABIs (so there are four builds total with the wide and
 narrow versions), use the ncurses-libs subpackage for the new ABI 6
 libs and create a new subpackage for ABI 5 libs. What would be a good
 name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5,
 or something else?

Ok, the new ncurses package is now in rawhide. The name of the ABI 5
subpackage is ncurses-compat-libs.

I've also rebuilt the readline package to pick up the new libtinfo.
Binaries that are linked with both readline and ncurses/libtinfo (e.g.
gdb, bc, sqlite3) will now load both versions of libtinfo into memory,
which I suspect could be a problem. I tried some of them and they
don't seem to crash, but we might want to rebuild the packages to be
safe anyway.

Here is a list of packages that seem to have binaries like that. I
suspect a lot of them are linked with ncurses unnecessarily.

Macaulay2-1.6-15.fc24: /usr/bin/M2
afpfs-ng-0.8.1-19.fc23: /usr/bin/afpcmd
afpfs-ng-0.8.1-19.fc23: /usr/bin/afpgetstatus
afpfs-ng-0.8.1-19.fc23: /usr/lib64/libafpclient.so.0.0.0
airinv-1.00.1-5.fc24: /usr/bin/AirInvClient
airinv-1.00.1-5.fc24: /usr/bin/AirInvServer
airinv-1.00.1-5.fc24: /usr/bin/airinv
airinv-1.00.1-5.fc24: /usr/bin/airinv_parseInventory
airinv-1.00.1-5.fc24: /usr/lib64/libairinv.so.1.00.1
airrac-1.00.1-4.fc24: /usr/bin/airrac
airrac-1.00.1-4.fc24: /usr/lib64/libairrac.so.1.00.1
airtsp-1.01.2-4.fc24: /usr/bin/airtsp
airtsp-1.01.2-4.fc24: /usr/lib64/libairtsp.so.1.01.2
apachetop-0.15.6-1.fc23: /usr/bin/apachetop
apt-0.5.15lorg3.95-21.git522.fc24: /usr/bin/apt-shell
asymptote-2.35-3.fc23: /usr/bin/asy
avrdude-6.1-3.fc23: /usr/bin/avrdude
bc-1.06.95-15.fc23: /usr/bin/bc
bird-1.5.0-1.fc23: /usr/sbin/birdc
bird6-1.5.0-1.fc23: /usr/sbin/birdc6
cadaver-0.23.3-10.fc23: /usr/bin/cadaver
cego-2.20.21-3.fc23: /usr/bin/cego
cego-2.20.21-3.fc23: /usr/bin/cgadm
cego-2.20.21-3.fc23: /usr/bin/cgblow
cego-2.20.21-3.fc23: /usr/bin/cgclt
cego-2.20.21-3.fc23: /usr/bin/cglog
cgdb-0.6.8-2.fc23: /usr/bin/cgdb
compat-guile18-1.8.8-11.fc24: /usr/lib64/libguilereadline-v-17.so.17.0.3
compat-lua-5.1.5-3.fc23: /usr/bin/lua-5.1
crash-7.1.2-1.fc23: /usr/bin/crash
ddd-3.3.12-22.fc23: /usr/bin/ddd
folks-tools-0.11.1-3.fc24: /usr/bin/folks-inspect
freehoo-3.5.3-19.20100314cvs.fc23: /usr/bin/freehoo
freetalk-4.0-0.3.rc4.fc23: /usr/bin/freetalk
freetds-0.91-15.git0a42888.fc22: /usr/bin/fisql
freetds-0.91-15.git0a42888.fc22: /usr/bin/tsql
ftp-0.17-69.fc23: /usr/bin/ftp
fuse-afp-0.8.1-19.fc23: /usr/bin/afpfsd
fuse-afp-0.8.1-19.fc23: /usr/bin/mount_afp
gdb-7.9.90.20150717-12.fc24: /usr/bin/gdb
gdl-0.9.5-9.fc24: /usr/bin/gdl
gdl-python-0.9.5-9.fc24: /usr/lib64/python2.7/site-packages/GDL.so
ghc-readline-1.0.3.0-7.fc23: 
/usr/lib64/ghc-7.8.4/readline-1.0.3.0/libHSreadline-1.0.3.0-ghc7.8.4.so
glusterfs-cli-3.7.3-1.fc24: /usr/sbin/gluster
glusterfs-server-3.7.3-1.fc24: 
/usr/lib64/glusterfs/3.7.3/xlator/features/snapview-server.so
glusterfs-server-3.7.3-1.fc24: /usr/sbin/glfsheal
gnokii-0.6.31-12.fc23: /usr/bin/gnokii
gnubg-1.04.000-1.fc22: /usr/bin/bearoffdump
gnubg-1.04.000-1.fc22: /usr/bin/gnubg
gnubg-1.04.000-1.fc22: /usr/bin/makebearoff
gnubg-1.04.000-1.fc22: /usr/bin/makehyper
gnubg-1.04.000-1.fc22: /usr/bin/makeweights
gnucap-0.35-16.fc23: /usr/bin/gnucap
gnucap-0.35-16.fc23: /usr/bin/gnucap-modelgen
gnugo-3.8-11.fc23: /usr/bin/gnugo
gnurobots-1.2.0-16.fc23: /usr/bin/gnurobots
gretl-1.10.1-3.fc23: /usr/bin/gretlcli
guile-2.0.11-6.fc23: /usr/lib64/libguilereadline-v-18.so.18.0.0
hugs98-2006.09-23.fc24: /usr/bin/ffihugs
hugs98-2006.09-23.fc24: /usr/bin/hugs
hugs98-2006.09-23.fc24: /usr/bin/runhugs
insight-7.8.50-6.20140827git.fc23: /usr/bin/insight
ipmitool-1.8.15-4.fc23: /usr/bin/ipmitool
ipmitool-1.8.15-4.fc23: /usr/sbin/ipmievd
kawa-2.0-2.fc23: /usr/bin/kawa
kitutuki-0.9.6-10.fc23: /usr/bin/kitutuki
kitutuki-0.9.6-10.fc23: /usr/lib64/libkitutuki.so.1.0
ldapvi-1.7-21.fc23: /usr/bin/ldapvi
libgda-tools-5.2.2-10.fc23: /usr/bin/gda-sql-5.0
libguestfs-tools-c-1.31.1-3.fc24: /usr/bin/guestfish
librep-0.92.5-1.fc23: /usr/lib64/rep/rep/io/readline.so
lua-5.3.0-4.fc23: /usr/bin/lua
malaga-7.12-18.fc23: /usr/bin/malaga
malaga-7.12-18.fc23: /usr/bin/mallex
maloc-1.5-9.fc23: /usr/lib64/libmaloc.so.1.0.0
mdk-1.2.8-2.fc23: /usr/bin/gmixvm
mdk-1.2.8-2.fc23: /usr/bin/mixasm
mdk-1.2.8-2.fc23: /usr/bin/mixguile
mdk-1.2.8-2.fc23: /usr/bin/mixvm
ngspice-23-8.fc21: /usr/bin/ngmakeidx
ngspice-23-8.fc21: /usr/bin/ngmultidec
ngspice-23-8.fc21: /usr/bin/ngnutmeg
ngspice-23-8.fc21: /usr/bin/ngproc2mod
ngspice-23-8.fc21: /usr/bin/ngsconvert
ngspice-23-8.fc21: /usr/bin/ngspice
nickle-2.77-8.fc23: /usr/bin/nickle
ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/cvs_realclean
ocaml-omake-0.9.8.6-0.rc1.fc24.20: /usr/bin/omake
octave-4.0.0-4.fc24: /usr/lib64/octave/4.0.0/liboctave.so.3.0.0
opendbx-utils-1.4.6-8.fc23: /usr/bin/odbx-sql
pal-0.4.3-12

Re: ncurses update to 6.0

[Miroslav Lichvar]

On Wed, Aug 05, 2015 at 08:34:56PM -0400, Neal Gompa wrote:
 On Aug 5, 2015 2:55 AM, Miroslav Lichvar mlich...@redhat.com wrote:
  On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote:
   Are you looking to do this for F23 branch and rawhide or just rawhide
   and have it land in F24 when it is ready? Or is that still to be
   determined.
 
  I was thinking about doing this in rawhide only with no
  ncurses-specific rebuilds. After the next mass rebuild everything
  that didn't FTBFS should be using the ABI 6 libs.

 If you can provide both versions, I don't see a reason to not provide it in
 Fedora 23 branch too. We could just not force a rebuild in the branch and
 do that only in rawhide.

I'm not sure, it seems odd to me to have packages in a Fedora release
which change their dependencies (e.g. libncurses.so.5 - libncurses.so.6)
after rebuild. Are others ok with that?

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ncurses update to 6.0

[Miroslav Lichvar]

On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote:
 On 4 August 2015 at 04:33, Miroslav Lichvar mlich...@redhat.com wrote:
  As for updating the ncurses package, my current plan is to build the
  libs in both ABIs (so there are four builds total with the wide and
  narrow versions), use the ncurses-libs subpackage for the new ABI 6
  libs and create a new subpackage for ABI 5 libs. What would be a good
  name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5,
  or something else?
 
 
 Are you looking to do this for F23 branch and rawhide or just rawhide
 and have it land in F24 when it is ready? Or is that still to be
 determined.

I was thinking about doing this in rawhide only with no
ncurses-specific rebuilds. After the next mass rebuild everything
that didn't FTBFS should be using the ABI 6 libs.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ncurses update to 6.0

[Miroslav Lichvar]

The ncurses upstream has released a first 6.0 version few months ago.
The default ABI version has changed to 6, which enables some
extensions to allow more colors, mouse wheel, etc. The ABI version 5
is still supported and can be selected with a configure option.

We should switch to the new ABI, but we will probably want to provide
the old ABI 5 libs even when all Fedora ncurses applications are
rebuilt with the new ABI to not break 3rd party packages. Dependency
on libncurses.so.5 or libtinfo.so.5 is pretty common.

As for updating the ncurses package, my current plan is to build the
libs in both ABIs (so there are four builds total with the wide and
narrow versions), use the ncurses-libs subpackage for the new ABI 6
libs and create a new subpackage for ABI 5 libs. What would be a good
name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5,
or something else?

Thoughts?

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libgps (gpsd) soname bump

[Miroslav Lichvar]

The gpsd package in rawhide will be updated to 3.13, it's in git now
and will be built later this week or the next week if there are no
objections.

It bumps the libgps soname and there are also small API changes,
probably the most important change is that some arrays (used, PRN,
elevation, azimuth, ss) in gps_data_t are now split into the skyview
array of satellite_t inside gps_data_t.

Please let me know if you have any troubles with updating clients.

The following packages seem to depend on libgps:

gpsdrive-0:2.11-26.fc22
marble-widget-1:14.12.2-1.fc23
plasma-workspace-0:5.2.1-2.fc23
qlandkartegt-0:1.8.1-2.fc23
qtgpsc-0:0.3.1-10.fc22
vfrnav-0:20141211-1.fc22
vifir-0:0.9-27.fc22
viking-0:1.5.1-3.fc22
xtide-0:2.14-2.fc22

A scratch build of gpsd is here: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=9120407

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: timedatex replacing systemd-timedated for NTP packages

[Miroslav Lichvar]

On Thu, Nov 27, 2014 at 01:19:48PM -0500, Miloslav Trmač wrote:
 - Original Message -
  One suggestion was to install it as a dependency of the NTP packages.
  Is this a good idea? Should this first go through the Fedora change
  process or at least be documented somewhere?
 
 I think having a package that “takes over” a D-Bus service name, and 
 installing it by default but not in all possible installations, is surprising 
 enough that it would benefit from a FESCo sanity check, yes.

Hm, yes, having two similar but not identical implementations of the
timedate interface and using one only when an NTP package is installed
could be a source of confusion.

Beside the selection of the NTP service that should enabled/disabled,
there are some minor differences in the functionality. For instance,
when setting the time, timedatex compensates for the time spent in the
polkit authorization check. E.g. running timedatectl set-time 12:00:00
and taking 5 seconds to type the password sets the clock to 12:00:05,
not 12:00:00.

Would it make more sense to always use timedatex in Fedora, even when
no NTP package is installed?

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: timedatex replacing systemd-timedated for NTP packages

[Miroslav Lichvar]

On Tue, Nov 25, 2014 at 02:35:12PM -0700, Chris Murphy wrote:
 On Tue, Nov 25, 2014 at 10:51 AM, Florian Weimer fwei...@redhat.com wrote:
  Some networks have bad NTP service in the sense that they hand out incorrect
  time (not just off by a few seconds, but days or months, enough to skew
  certificate validity).
 
 I'm not sure what we're supposed to do about such sabotage on the
 network, that seems distinctly a local issue. We should do the best we
 can right now, while providing a manual switch for the user to alter
 the default.
 
 It used to be the case that we used these servers:
 0.fedora.pool.ntp.org
 1.fedora.pool.ntp.org
 2.fedora.pool.ntp.org
 3.fedora.pool.ntp.org

We still do. Unless the number of bad servers added from DHCP is large
enough to disrupt the NTP source selection algorithm or the pool
servers are not reachable (NTP traffic blocked), it shouldn't be a big
problem. Of course, without authentication this can't reliably protect
against MITM attacks.

  Now if Fedora offered a high-availability cryptographic time service (we
  actually do, sort of), things might be different—but not much, because then
  we'd be having a discussion about phoning home instead.
 
 The pool still exists. Are we not supposed to use them?

I think Florian meant getting time over HTTPS from a Fedora server.
The tlsdate program could be used for that. I'm not sure what
resources would be needed to allow this to be enabled by default. The
NTP Autokey protocol would be probably more efficient (and accurate),
unfortunately it doesn't work behind NAT.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

timedatex replacing systemd-timedated for NTP packages

[Miroslav Lichvar]

This is about bug #1136905 [1], discussed previously on the systemd list
[2] and also on our desktop list [3].

The issue is that systemd-timedated now supports only systemd-timesyncd
for NTP and ignores other NTP services installed on the system. It doesn't
know that chronyd or ntpd is enabled (usually by system-config-date after
the installation) and switching NTP in timedate clients such as
timedatectl and GNOME control center is broken.

If we want to have this working correctly with chronyd/ntpd, at this point
it seems the only reasonable option is to replace systemd-timedated.
timedatex is a new implementation of the timedate interface that was
recently added to Fedora. It reads the list of NTP units from a directory
as systemd-timedated used to do. When installed, systemd will start it for
the timedate bus name instead of systemd-timedated. The timedate clients
should work as expected, please report bugs if not.

One suggestion was to install it as a dependency of the NTP packages.
Is this a good idea? Should this first go through the Fedora change
process or at least be documented somewhere?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1136905
[2] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022367.html
[3] http://lists.fedoraproject.org/pipermail/desktop/2014-September/010749.html

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New Group Calls For Boycotting Systemd

[Miroslav Lichvar]

On Mon, Sep 08, 2014 at 08:36:21AM -0500, Michael Catanzaro wrote:
 On Sun, 2014-09-07 at 22:18 -0700, Adam Williamson wrote:
- has tools for setting the system time and timezone, and locale
  
  Sure. They're useful.
 
 In GNOME, our settings panels previously only worked on Fedora and
 Debian, with some half-functional code for Arch and openSUSE, because
 each distro handled these differently and required custom code. Now we
 have no special casing for different distros, and it works everywhere
 these D-Bus interfaces are present (including systems without systemd
 that provide it, like Ubuntu).

Yeah, that was nice, when it worked as we wanted. Unfortunately, with
the latest systemd the NTP service which is enabled/disabled by
timedated is no longer selected from the services installed on the
systemd, but is now hardcoded to the systemd SNTP client (timesyncd).

That means the NTP status reported in GNOME settings may be incorrect,
enabling/disabling NTP will do nothing if another NTP service is enabled
or timesyncd will be enabled even when our default NTP client
(chronyd) is installed.

https://bugzilla.redhat.com/show_bug.cgi?id=1136905

Upstream is not interesting in having this configurable. Should we be
patching timedated? Or GNOME?

 I don't really care where these interfaces live, but they need to exist
 somewhere, and systemd seems like the logical place for them.

Agreed, the problem is systemd upstream may have a different view on
what exactly the interfaces should do.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: May I file 1000 bugs aka upstream test suite tracking

[Miroslav Lichvar]

On Fri, Feb 21, 2014 at 02:50:12PM +, Daniel P. Berrange wrote:
 On Fri, Feb 21, 2014 at 09:38:56AM -0500, Josh Boyer wrote:
  Personally, I don't think %check is a good idea at all.
 
 I think the benefit depends on the level of patching the Fedora maintainer
 is doing. If they are shipping just vanilla upstream tar.gz then they can
 have a moderate level of confidence in the functionality of their package
 without tests, since you can assume upstream ran their test before release.

Upstream may not have run the test on all archs supported by Fedora.
ARM is probably still not something we can assume everyone has. I was
dealing with a test which failed only on 32-bit systems just
yesterday, I didn't notice it until I tried building the package in
koji.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gpsd soname bump

[Miroslav Lichvar]

The gpsd package in rawhide has been updated to 3.10 and the libgps
soname has changed. The following packages need to be rebuilt. I don't
expect any problems, but please let me know if something does break.

foxtrotgps-1.1.1-6.fc20
gpsdrive-2.11-20.fc20
kde-workspace-4.11.3-4.fc21
marble-4.11.95-1.fc21
qlandkartegt-1.7.5-1.fc21
qtgpsc-0.3.1-7.fc20
vfrnav-20130920-1.fc21
vifir-0.9-19.fc20
viking-1.4.1-2.fc20
xtide-2.13.2-2.fc20

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ntp-4.2.6p5-11.fc19.src.rpm does not rpmbuild...

[Miroslav Lichvar]

On Fri, Oct 18, 2013 at 02:14:40PM +0100, Barry Scott wrote:
 On Thu 17 Oct 2013 17:56:57 Barry Scott wrote:
  I need to patch ntp for my uses. But I find that the src rpm will not build
  on F19.
  
  cd .  env
  PATH=/home/bscott/rpmbuild/BUILD/ntp-4.2.6p5/ntpd:/home/bscott/bin:/usr/loc
  al/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin autogen -L ../include
  --writable -Tagman1.tpl -bntpd ntpd-opts.def ice-9/psyntax.scm:1259:12: In
  procedure dobody:
  ice-9/psyntax.scm:1259:12: Syntax error:

That looks like https://bugzilla.redhat.com/show_bug.cgi?id=958908.

It's fixed in autogen-5.18-1.fc20. The F19 ntp spec includes a
workaround touch ntpd/ntpd.1 util/ntp-keygen.1, which prevents
autogen from rebuilding the man pages. If you are patching other
autogen files in the ntp code, you'll need to update the autogen
package or similarly touch the other man pages.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Non-responsive maintainer: Anthony Green

[Miroslav Lichvar]

I'm having troubles contacting Anthony Green (username green). I'd
like to comaintain the autogen package. There is a number of bugs
which should be addressed [1], but my request for commit access is
unanswered. I didn't get any reply on email or IRC. The last commit he
made in the autogen package is from Nov 25 2011. Has anyone heard from
him recently?

It has not been three weeks since my first attempt to contact him (as
per the policy) yet, but I noticed there are other unanswered acl
requests in the libffi and ws-commons-utils packages, so I thought
others may be waiting for his response too.

[1] https://admin.fedoraproject.org/pkgdb/acls/bugs/autogen

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 01:48:04PM -0700, Adam Williamson wrote:
 On Wed, 2013-07-17 at 13:44 -0700, Adam Williamson wrote:
  On Wed, 2013-07-17 at 16:09 +0200, Miroslav Lichvar wrote:
  
e. Why isn't this functionality being added to chrony, rather than 
bouncing us back to ntpd?
   
   Which functionality exactly? Both ntpd and chronyd (in default
   configuration) let the kernel sync the RTC. 
  
  The ability to invoke chronyd in a way that mimics ntpdate. This thread
  has turned up that you can invoke *ntpd* in this way: ntpd -q -g -x. But
  no-one has yet provided an equivalent invocation for chronyd, and I
  could not figure one out from the manpage.

chronyd doesn't have an ntpdate mode. I think that could be a
useful feature and I'll see if it can be added.

  Aside from anything else, anaconda requires something like this to be
  available in order to check whether an NTP server is valid and
  available: a simple, one-off command which will 'return true' in some
  obvious way if the specified server exists and responds correctly, and
  'return false' if it doesn't. For now it is using ntpdate; I suppose we
  could switch it to ntpd, but it would make an awful lot more sense if
  chronyd could do this.
 
 In fact, now I look at it, ntpd as it stands cannot replace ntpdate for
 anaconda's purposes, because anaconda calls ntpdate with the -q option,
 which means query only, do not set the clock - obviously, this is
 appropriate when we just want to test the functionality of an NTP
 server. ntpd does not have an equivalent option.

The sntp tool can be used instead of ntpdate to test if an NTP server
is responding.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd (fwd)

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 01:56:13PM -0400, Paul Wouters wrote:
 Okay, so perhaps chrony should be extended to use a saved clock as a
 time source on boot if available, and save the time in a file regularly,
 if it does not do so already.

I'd say that should be a new separate service run on boot and
shutdown. As we have learned in the other thread, the chronyd service
can't even know if it's started for the first time after boot and
should restore the time from the file, or was just restarted.

 ObPetPeve: The complete chrony documentation is supplied in texinfo format.

Is texinfo no longer considered acceptable? The documentation is
included also as plain text in /usr/share/doc/chrony-1.28/chrony.txt
if you don't like the info format.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?

[Miroslav Lichvar]

On Tue, Jul 16, 2013 at 09:47:39PM +0200, Lennart Poettering wrote:
 On Tue, 16.07.13 21:10, Miroslav Lichvar (mlich...@redhat.com) wrote:
  Possibly related question: Is there a way to start a daemon with
  different options on restart than on start, something like
  ExecRestart?
 
 No. And I am not convinced that that's a good idea to have.

Is this one of the never going to happen things or could you be
convinced?

  This would allow restarting chronyd with the -r option to load old
  samples and speed up the initial synchronization.
 
 Hmm, this sounds like something to maybe just solve based on a simple
 time scheme? i.e. reuse if the old samples are not older than 1h or so?

I don't think a time check would be reliable here. The samples should
be loaded only when they are still valid, i.e. nothing else has
touched the clock. It improves the initial response if used
correctly, but makes it much worse if used with invalid samples.
And chronyd can't know how good are the samples until it's too late.

The safest approach is to use in only when the service is restarted.
It must not be used when someone stops the service, runs ntpdate and
starts chronyd again.

An even better example might be the -R option, which tells chronyd to
not step the clock on start. If it was used on service restart, we
would be sure there are no time jumps when the chrony package is
upgraded.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 12:43:41PM +0200, Jaroslav Reznik wrote:
 https://fedoraproject.org/wiki/Changes/ntpdate
 
 Change owner(s): Michael Harris MikeDawg (at) gmail (dot) com 

 ntpdate is slowly being depricated in favor of ntpd. DoD STIGs now penalize 
 for the use of ntpdate on Red Hat Enterprise systems. I would like to 
 modernize the ntpdate utility to do two things.
 
 First, I would like to get rid of the dependency of ntpdate, in favor of ntpd.

Which dependency exactly do you want to get rid of? The ntpdate
service is disabled by default and AFAIK it needs to enabled manually.

 Second, I would like to add a set time and/or randomized time for ntpd to 
 check for time updates (as configured by the user in /etc/sysconfig/ntpdate).
 
 I'm thinking of using ntpd with the -q option to immediately exit the daemon 
 after it runs. 

Please note that there is an official replacement for ntpdate called
sntp, which is in the sntp subpackage of ntp and it includes a service
similar to ntpdate.

 == Scope ==
 Proposal owners: Need to re-engineer the startup task for ntpdate ( 
 /etc/init.d/ntpdate, NOT /usr/sbin/ntpdate ); or figure out if this is 
 something that is more easily created via a cron job. Format 
 /etc/sysconfig/ntpdate to accept additional options, as discussed above.

If you want to have something that calls sntp (or ntpd -q)
periodically, please consider using the systemd timers. It's very
important that the time when the program is executed is not aligned to
any second/minute/hour (as it would be with cron) to avoid flooding
the public NTP servers.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 07:59:11AM -0600, Chris Murphy wrote:
 
 a. ntpd/ntpdate aren't installed by default with Fedora 19. I don't see the 
 feature proposing this be changed.

Also, there is already a replacement for ntpdate, it's in the sntp
package.

 b. A default installation of Fedora 18/19, has no means of updating the RTC 
 correctly if it's off by more than 15 minutes; and 60 minutes with newer 
 kernels. An RTC wrong by more than an hour, e.g. two months ago, if I have an 
 internet connection chrony sets the system clock to the correct date/time. If 
 I don't have an internet connection, I'm relegated to a system time based on 
 the wrong RTC, which seems grossly broken to me. 

It was fixed in kernel 3.10, which should be in f19 soon.

 d. This long bug, 816752, suggests, as a solution, installing ntpdate in 
 order to set the RTC. So if ntpdate is being deprecated as part of the 
 proposed feature, why is installing and using ntpdate being suggested as a 
 fix for the lack of chrony-kernel RTC sync support?
 https://bugzilla.redhat.com/show_bug.cgi?id=816752#c75
 
 e. Why isn't this functionality being added to chrony, rather than bouncing 
 us back to ntpd?

Which functionality exactly? Both ntpd and chronyd (in default
configuration) let the kernel sync the RTC. 

 The time situation on Fedora makes me think the left hand and right hand are 
 doing different things.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 08:41:23AM -0600, Chris Murphy wrote:
 
 On Jul 17, 2013, at 8:09 AM, Miroslav Lichvar mlich...@redhat.com wrote:
 
  It was fixed in kernel 3.10, which should be in f19 soon.
 
  Which functionality exactly? Both ntpd and chronyd (in default
  configuration) let the kernel sync the RTC. 
 
 OK I just set the RTC clock wrong by two months, manually and then I've 
 rebooted 3.10.0-1.fc20.x86_64 on Fedora 19.
 
 The system clock is updated by chrony, correctly.
 
 The RTC is not being updated. It still thinks it's May.

You might need to wait a bit longer. It worked for me the last time I
tried, but it took almost 2 hours for the kernel to sync the RTC. From
the kernel code it seems the RTC update should happen quickly after
the unsynchronized flag in the kernel is cleared and then at most at
11 minute intervals. Please file a new bug.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?

[Miroslav Lichvar]

On Wed, Jul 17, 2013 at 03:47:27PM +0200, Lennart Poettering wrote:
 On Wed, 17.07.13 11:29, Miroslav Lichvar (mlich...@redhat.com) wrote:
  An even better example might be the -R option, which tells chronyd to
  not step the clock on start. If it was used on service restart, we
  would be sure there are no time jumps when the chrony package is
  upgraded.
 
 But for -R even more looking at the clock is actually the better choice
 and already what happens, no? I mean, the stepping is only done if the
 time difference is greater than some threshold. That sounds like a much
 better solution, since it always works.

The clock could be so bad (think virtual machines) that it can't be
constantly kept below the threshold. Unlikely, but certainly possible.
The -R option would guarantee there are no steps after the first
start.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?

[Miroslav Lichvar]

On Mon, Jul 15, 2013 at 10:55:59PM +0200, Lennart Poettering wrote:
 If I grok correctly what you are asking for, you are actually looing for
 an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run
 before we stop a service when we intend to restart it. But when we
 shutdown the system and stop the service for that, or if the user wants
 to stop it manually, we shouldn't run it, correct?
 
 If that's what you want, then yes, it is on the TODO list to add
 something like this, but ExecStopPre= is not what you want, it would
 have very different semantics.

Possibly related question: Is there a way to start a daemon with
different options on restart than on start, something like
ExecRestart?

This would allow restarting chronyd with the -r option to load old
samples and speed up the initial synchronization.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compile-time shared library name mismatching base name (SDL)

[Miroslav Lichvar]

On Mon, Jul 01, 2013 at 09:36:19AM +, Petr Pisar wrote:
 root@fedora-20:~ # ls -o /usr/lib64/libSDL*
 lrwxrwxrwx. 1 root 20 Jul  1 10:43 /usr/lib64/libSDL-1.2.so.0 - 
 libSDL-1.2.so.0.11.4
 -rwxr-xr-x. 1 root 444176 Jun 19 12:58 /usr/lib64/libSDL-1.2.so.0.11.4
 lrwxrwxrwx. 1 root 20 Jul  1 10:55 /usr/lib64/libSDL.so - 
 libSDL-1.2.so.0.11.4

 root@fedora-20:~ # ldconfig -v |grep SDL
 ldconfig: Can't stat /libx32: No such file or directory
 ldconfig: Path `/usr/lib' given more than once
 ldconfig: Path `/usr/lib64' given more than once
 ldconfig: Can't stat /usr/libx32: No such file or directory
 libSDL-1.2.so.0 - libSDL.so
 
 If I remove the libSDL.so, then ldconfig leaves this silly idea and
 returns to expected value (libSDL-1.2.so.0 - libSDL-1.2.so.0.11.4).

 Is adding the libSDL-1.2.so symlink (and preserving libSDL.so) for
 backward compatibility wise?

Perhaps the best option would be to rename the symlink and replace it
with a linker script containing just INPUT(-lSDL-1.2) to keep
ldconfig happy. This is how it's done in the ncurses-devel package for
libcurses.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Compile-time shared library name mismatching base name (SDL)

[Miroslav Lichvar]

On Thu, Jul 04, 2013 at 05:39:02PM +0200, Florian Weimer wrote:
 On 07/04/2013 03:29 PM, Miroslav Lichvar wrote:
 Perhaps the best option would be to rename the symlink and replace it
 with a linker script containing just INPUT(-lSDL-1.2) to keep
 ldconfig happy. This is how it's done in the ncurses-devel package for
 libcurses.
 
 Unless I'm missing something, this is fairly common (see the
 attachment).  Perhaps changing ldconfig is better?

I think there was a reason why ldconfig did it, but I'm not sure what
it was. You might want to ask the glibc maintainers.

 gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgps.so.20.0,libgps.so.20
 gpsd-libs-3.9-1.fc19.i686,/usr/lib/libgpsd.so.21.0,libgpsd.so.21
 gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgps.so.20.0,libgps.so.20
 gpsd-libs-3.9-1.fc19.x86_64,/usr/lib64/libgpsd.so.21.0,libgpsd.so.21

These look good to me.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel