Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: Workflow improvement suggestions for security releases
(Kyle Hall)
2. Re: Issues fetching from Koha Git due to Let's Encrypt root
certificate expiry (Fridolin SOMERS)


----------------------------------------------------------------------

Message: 1
Date: Thu, 7 Oct 2021 07:15:43 -0400
From: Kyle Hall <kyle.m.hall@gmail.com>
To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Cc: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Workflow improvement suggestions for
    security releases
Message-ID:
    <CACpVHfw8zpDd8B2hkO-fHKOrg1n+Q_efoq-C3BTLb+VB5=-ktg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

>
> 1. LTS
> I think it's time to have a Long Term Support release. We noticed that
> some people are still using very old versions, having a version that
> is maintained several years could help them.
> We could backport critical security bugs only. 4 (5?) years would be great.
>

This has been proposed in the past. The general consensus at the time was
that we as a community want to encourage libraries to stay on the latest
versions of Koha and not to hang back on older versions.
I'm not necessarily opposed, but such a role will require quite a
commitment.


> 2. Communication
> Once the issues have been reported and fixed, I've alerted the first
> cycle of people around me. Their job was to alert a second cycle.
> Should we have a list of people we trust? Ask the (general) mailing
> list who wants to be in the loop? That means adding them to the
> security group on bugzilla (or at least adding them when the bug has a
> fix) and CC them when private discussions take place.
>

Sounds good!


> 3. Synchronisation
> Release maintainers are spread around the world (and timezones suck).
> Getting feedback can take time, several days (like: "try", "don't
> work", "try again", it's 3 days!).
> Then when you plan to release on Wednesday, and things are only ready
> on Thursday you need to wait until Monday as part of the world is
> still enjoying the weekend!
> I don't have a solution for that, apart from the Monday postpone or...
> more anticipation.
> Same problem for the time of the release, I've picked 12 UTC as the
> "most convenient" slot for a release, but it won't (ofc) fit
> everybody's needs. My point was that if we communicated enough
> beforehand (but not publicly) it should not be a problem.
> Let me know if you have ideas to improve that!
>

We can already schedule our news posts in advance. Perhaps rmaints should
have a non-public area on the ftp server where we could put our tarballs
and such, and a cronjob that would automatically move them to the public
folder and update the symlinks at 12 UTC every day ( if there are files to
move ). I'm not sure how to synchronize the community apt server into this,
but I imagine it could be done. If we get into the habit of scheduling
everything for release at 12 UTC, security release or not, we can probably
get pretty good at it, ironing out the kinks before we have another
security release to deal with.


> 4. Infrastructure improvement
> We don't have CI/Jenkins for the security repository. We need one!
> That must be a top priority of the next cycle. We need to help RMaints
> and make the security release process easier and less stressful.
>

Agreed!


> 5. Apply patches
> We need a script to apply the patches on the different branches,
> automatically. That's an easy bit to develop and it will help us a
> lot.
>

I'm not sure what you mean? Do you mean something that would apply a bug's
patch set to say master, stable and oldstable and report on the bug if it
doesn't apply to one? Or script in qa-test-tools to do that? Something else
entirely?


> 6. More visibility on the status of the patches
> RM and RMaints must put their progress on the bug report itself. A
> comment "Will be pushed, RM had a look at this" or "Backported for..."
> should be added.
> That must be added to the "Release process" wiki page.
>

Sounds good!

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211007/57bef723/attachment-0001.htm>

------------------------------

Message: 2
Date: Thu, 7 Oct 2021 20:17:56 -1000
From: Fridolin SOMERS <fridolin.somers@biblibre.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Issues fetching from Koha Git due to Let's
    Encrypt root certificate expiry
Message-ID: <6112e5a7-1f0c-cf11-a017-c44b15125b9d@biblibre.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Thanks a lot David.
This certificate expiry has many huge impacts, like some package
repositories acess.
Be sure to upgrade all your servers.

Best regards

Le 05/10/2021 à 18:56, dcook@prosentient.com.au a écrit :
> Hi all,
>
> Some people might have found they aren’t able to fetch from the Koha Git
> (in koha-testing-docker for instance). They might be getting the
> following error:
>
> fatal: unable to access
> 'https://git.koha-community.org/Koha-community/Koha.git/': server
> certificate verification failed. CAfile: none CRLfile: none
>
> That seems to be due to the Let’s Encrypt root certificate expiry. I
> imagine the latest koha-testing-docker probably doesn’t have this
> problem, but if you’re lazy or time poor like me, you can just run the
> following to get your existing koha-testing-docker to work again:
>
> apt-get update
>
> apt-get install ca-certificates
>
> Cheers,
>
> David Cook
>
> Senior Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>

--
Fridolin SOMERS <fridolin.somers@biblibre.com>
Software and system maintainer 🦄
BibLibre, France


------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 191, Issue 5
******************************************