Bug 222376 - security/kc: Update to 2.4.2
Summary: security/kc: Update to 2.4.2
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kurt Jaeger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-16 20:41 UTC by Vidar Karlsen
Modified: 2018-07-28 10:49 UTC (History)
3 users (show)

See Also:
pi: maintainer-feedback+


Attachments
svn diff (1.29 KB, patch)
2017-09-16 20:41 UTC, Vidar Karlsen
no flags Details | Diff
svn diff that adds kc24 and deprecates the old kc in a year (4.30 KB, patch)
2018-02-24 19:54 UTC, Vidar Karlsen
vidar: maintainer-approval?
Details | Diff
Tweak of the previous diff for 2.4.2 (4.14 KB, patch)
2018-04-20 13:11 UTC, Daniel
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vidar Karlsen 2017-09-16 20:41:15 UTC
Created attachment 186438 [details]
svn diff

The current version in the ports tree (2.3.2) was released 14 Dec 2013.
2.4.1 was released 26 Nov 2015, but hasn't made it into the ports tree yet.

portlint -C: looks fine.

poudriere testport ok:
10.3-RELEASE amd64
10.3-RELEASE i386
10.3-RELEASE arm.armv6
11.0-RELEASE amd64
11.0-RELEASE i386
11.0-RELEASE arm.armv6
11.1-RELEASE amd64
11.1-RELEASE i386
Comment 1 Daniel 2017-09-18 13:59:05 UTC
This is a perfectly valid point, however, v2.4 has introduced a new database file format that is incompatible with the older one (<2.4).
As I'm not that well versed in the FreeBSD ports infrastructure, and I really don't know how to handle this transition, the port had unfortunately stuck at this version.
Comment 2 Vidar Karlsen 2017-09-18 15:51:14 UTC
I see, perhaps the best way forward is to create a new port (kc24) with bundled instructions on how to convert from the old database format?
Comment 3 Daniel 2017-09-18 16:18:17 UTC
I'm up for it. I mean, if this is the way to go, and a customary way to handle this case in FreeBSD, then I'll submit a new port for kc24.
Should we perhaps ask a "ports janitor"?
Comment 4 Steve Wills freebsd_committer 2017-10-23 21:15:10 UTC
(In reply to leva from comment #3)
That's a fine way to handle it. In this case, you probably want to go ahead and pick an expiration time for when to get rid of the old version. So please submit a patch which creates the new version and sets the deprecation/expiration for the old one.
Comment 5 Yuri Victorovich freebsd_committer 2018-02-24 11:14:04 UTC
ping
Comment 6 Vidar Karlsen 2018-02-24 19:54:25 UTC
Created attachment 190971 [details]
svn diff that adds kc24 and deprecates the old kc in a year

Then I propose this patch.
It:
- adds security/kc24 as a new port with options PCRE SCRYPT LIBEDIT READLINE and a pkg-message with a warning about the incompatible database format
- deprecates security/kc on 2019-03-01 (change the date if it should be different)
- makes sure the two ports CONFLICT with each other

I've tested that it builds and runs on:
FreeBSD 10.3 amd64/i386
FreeBSD 10.4 amd64/i386
FreeBSD 11.1 amd64/i386

portlint -C: looks fine (on both)
Comment 7 Daniel 2018-03-01 09:03:46 UTC
Thank you for picking this up!

One note from me would be to not enable READLINE explicitly, because runtime editline and readline support is mutually exclusive. By default (if you don't define READLINE at compile time, that is) it'll use libedit, and this was the case with the previous version.
I think this should stay the same.


Daniel
Comment 8 Vidar Karlsen 2018-03-01 19:37:17 UTC
(In reply to leva from comment #7)
That is the idea. It keeps LIBEDIT as a default enabled option:
OPTIONS_DEFAULT=PCRE SCRYPT LIBEDIT

and gives the user radio buttons to choose between LIBEDIT and READLINE:
OPTIONS_RADIO_CLI=LIBEDIT READLINE

When compiled with READLINE, it gets linked to libreadline.so:
root@fbsd11-1-portswrk:~ # ldd /usr/local/bin/kc
/usr/local/bin/kc:
	libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a00000)
	libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x800e69000)
	libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0x8011fe000) <---
	libncurses.so.8 => /lib/libncurses.so.8 (0x80144f000)
	libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8016a4000)
	libscrypt.so.0 => /usr/local/lib/libscrypt.so.0 (0x80191f000)
	libc.so.7 => /lib/libc.so.7 (0x801b26000)
	libz.so.6 => /lib/libz.so.6 (0x801ede000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8020f7000)
	libm.so.5 => /lib/libm.so.5 (0x802320000)
	libncursesw.so.8 => /lib/libncursesw.so.8 (0x80254b000)
	libthr.so.3 => /lib/libthr.so.3 (0x8027a9000)

When compiled with LIBEDIT, it gets linked to libedit.so:
root@fbsd11-1-portswrk:~ # ldd /usr/local/bin/kc
/usr/local/bin/kc:
	libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a00000)
	libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x800e69000)
	libedit.so.0 => /usr/local/lib/libedit.so.0 (0x8011fe000) <---
	libncursesw.so.8 => /lib/libncursesw.so.8 (0x801432000)
	libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x801690000)
	libscrypt.so.0 => /usr/local/lib/libscrypt.so.0 (0x80190b000)
	libc.so.7 => /lib/libc.so.7 (0x801b12000)
	libz.so.6 => /lib/libz.so.6 (0x801eca000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8020e3000)
	libm.so.5 => /lib/libm.so.5 (0x80230c000)
	libncurses.so.8 => /lib/libncurses.so.8 (0x802537000)
	libthr.so.3 => /lib/libthr.so.3 (0x80278c000)

While most will probably prefer the default, I figured it would be nice to provide a means to use readline in case anyone wants that, since it already supports it.

Please let me know if I'm misunderstanding something.
Comment 9 Daniel 2018-03-06 14:07:33 UTC
(In reply to Vidar Karlsen from comment #8)
You are absolutely right, I totally misread your diff. Ok for me!


Daniel
Comment 10 Daniel 2018-04-20 13:11:03 UTC
Meanwhile there's a new minor release, 2.4.2.
Comment 11 Daniel 2018-04-20 13:11:30 UTC
Created attachment 192680 [details]
Tweak of the previous diff for 2.4.2
Comment 12 Daniel 2018-06-24 21:22:48 UTC
What's happening here? Do you need something else from me?
Comment 13 Kurt Jaeger freebsd_committer 2018-07-28 05:35:32 UTC
testbuilds@work
Comment 14 Kurt Jaeger freebsd_committer 2018-07-28 05:37:32 UTC
Can you provide an example on how to dump the data and how to re-import the data to pkg-message ?
Comment 15 Kurt Jaeger freebsd_committer 2018-07-28 05:38:04 UTC
testbuilds are fine.
Comment 16 Daniel 2018-07-28 09:39:46 UTC
(In reply to Kurt Jaeger from comment #14)
Absolutely! It's in detail in the Changelog file.

Daniel
Comment 17 Kurt Jaeger freebsd_committer 2018-07-28 10:13:54 UTC
I modified pkg-message. I'm a bit torn because pkg-message will be displayed
after kc24 is installed, so it would be too late for the unlucky user.

How difficult would it be to provide a dumpold-like command that
reads old-style database files ?

Well, in the pkg-tree one can go back by installing kc instead of kc24,
but still...
Comment 18 Daniel 2018-07-28 10:16:55 UTC
Don't you have some means to display this before it gets installed?
Comment 19 commit-hook freebsd_committer 2018-07-28 10:42:52 UTC
A commit references this bug:

Author: pi
Date: Sat Jul 28 10:41:57 UTC 2018
New revision: 475519
URL: https://svnweb.freebsd.org/changeset/ports/475519

Log:
  New port: security/kc24

  Console based password storing application using an encrypted XML
  document as its database.

  WWW: https://github.com/levaidaniel/kc

  Please read the UPDATING note!

  PR:		222376
  Submitted by:	Vidar Karlsen <vidar@karlsen.tech>, Daniel <leva@ecentrum.hu> (maintainer and upstream-author)
  Relnotes:	https://github.com/levaidaniel/kc/blob/35656e47a36e96440eb5cc9e4f8a856856831e9a/Changelog

Changes:
  head/UPDATING
  head/security/Makefile
  head/security/kc/Makefile
  head/security/kc24/
  head/security/kc24/Makefile
  head/security/kc24/distinfo
  head/security/kc24/pkg-descr
  head/security/kc24/pkg-message
Comment 20 Kurt Jaeger freebsd_committer 2018-07-28 10:43:52 UTC
I'm not aware of any hook to display a pre-installation message.

It's committed now, with some hints.
Comment 21 Daniel 2018-07-28 10:45:04 UTC
That's interesting. How do you handle eg. PostgreSQL upgrades to new, incompatible versions?
Comment 22 Kurt Jaeger freebsd_committer 2018-07-28 10:49:15 UTC
We cope with the UPDATING entries. It's not perfect, I'm aware.