BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-05T07:43:44Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1573Rewrite qmin ans.py services2021-10-05T07:43:44ZWitold KrecickiRewrite qmin ans.py servicesLong-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2800Docker image for AArch64 - Raspberry Pi2022-02-01T11:18:07ZVicky Riskvicky@isc.orgDocker image for AArch64 - Raspberry PiI received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supp...I received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supported for the AArch64 architecture."Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/822Follow-up from "GitLab CI cleanup"2019-02-05T20:13:15ZOndřej SurýFollow-up from "GitLab CI cleanup"The following discussion from !1329 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1329#note_38876): (+3 comments)
> Without rebasing, I renamed CI jobs as agreed...The following discussion from !1329 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1329#note_38876): (+3 comments)
> Without rebasing, I renamed CI jobs as agreed upon earlier; the diff from the previous version of the branch looks fairly legible to me.
>
> @ondrej, I think this achieves what you asked for, but please take a look at https://gitlab.isc.org/isc-projects/bind9/pipelines/8771 to confirm that.
>
> While examining job output for the pipeline linked to above, I noticed an issue which was not introduced by this branch: the job testing `make install` does not just install stuff, but rather does an almost complete rebuild first. This is caused by how artifacts are passed between jobs: when a runner for the "install" job clones the tested revision and subsequently extracts the artifacts that the "build" job produced, modification times for the versioned source files inside the working copy turn out to be more recent than the timestamps of the object files extracted from the artifacts archive. This causes `make` to believe that it needs to rebuild stuff.
>
> I see no elegant way to solve this, because:
>
> * Updating the timestamps for all files and directories in the working copy for the "install job" to the same value (e.g. using `find . | xargs touch`) does us no good as that would also cause rebuilds (since dependencies are built in a specific order and this order has to be reflected in timestamps in order for a rebuild to be prevented).
>
> * We could store the modification time for each file created by the "build" job in a separate file and then, in the "install" job, update the timestamp for each file extracted from the artifacts archive to the stored timestamp + some constant delta, but that would trigger a lot of *"Warning: File 'Makefile' has modification time XXXX s in the future"* messages in the job output (though I believe it would achieve the desired effect).
>
> * The above warnings cannot be fully prevented from appearing even if we calculated the timestamp delta dynamically in the "install" job (e.g. "move timestamps for all extracted files by the difference between current time and the lowest timestamp found amongst all the extracted files") as the "install" job runs quicker than the "build" job.
>
> I believe our options here are:
>
> * Ignore this and just let the "install" job rebuild stuff.
>
> * Choose the second approach listed above, ignoring the warnings about timestamps set in the future.
>
> * Run `make install` in the "build" job (theoretically, this might delay the start of the entire "Test" phase of the pipeline, but I do not think it would be noticeable, given the statistical differences in run time between various jobs in the "Build" phase).
>
> @ondrej, thoughts, any other ideas for addressing this?Long-termMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/691Add thread safety testing in the CI2021-03-04T15:27:01ZOndřej SurýAdd thread safety testing in the CIWe should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on...We should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on the release branches in the Jenkins CI, and build the tools to compare the TS and Helgrind results, and use those tools to have a GitLab CI job that would not allow regressions.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/469Typo in validate-glue branch2018-11-08T17:40:01ZOndřej SurýTypo in validate-glue branchThe !300 introduced typo (it can be seen in the review history) `!!validate` should be `!validate`.
The thing that troubles me most, that it wasn't detected by the tests, so together with fixing the typo, the test should be prepared to ...The !300 introduced typo (it can be seen in the review history) `!!validate` should be `!validate`.
The thing that troubles me most, that it wasn't detected by the tests, so together with fixing the typo, the test should be prepared to catch this kind of error.Long-termEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/463Socket layer alternative based on libuv2021-06-03T15:01:18ZWitold KrecickiSocket layer alternative based on libuvFirst part of #29First part of #29Long-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/303Improve const correctness2021-10-04T12:47:58ZOndřej SurýImprove const correctness@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writ...@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writing new code and doing reviews.
It is a long term goals, so we will just keep this open, and I'll list major components that should be reviewed:
* [ ] libisc
* [ ] libdns
* [ ] libns
* [ ] libisccfg
* [ ] libiscccc
* [ ] bin/namedLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/250Replace ATF+Kyua with something lighter2018-06-20T10:38:42ZOndřej SurýReplace ATF+Kyua with something lighterThe ATF suite is really heavyweight, and we are not really using it's full potential. Something simpler like [C-TAP Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) could be used instead.
Requirements:
* Support for all o...The ATF suite is really heavyweight, and we are not really using it's full potential. Something simpler like [C-TAP Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) could be used instead.
Requirements:
* Support for all our supported platforms (Linux, BSDs)
* Support for all our best-effort platforms (Windows, Solaris) (?)
* Support for mocking objects
* Support for catching assertions
* Output in Test Anything Protocol
* Output in xUnit/jUnit
* Active upstream developmentLong-termOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/31[RT# 43887] [Support#10468] Implement ANAME draft to support apex CNAMEs2021-10-04T12:17:48ZVicky Riskvicky@isc.org[RT# 43887] [Support#10468] Implement ANAME draft to support apex CNAMEsRT 43887. Multiple subscribers have requested support for a solution for apex cnames. See the RT ticket for more details.RT 43887. Multiple subscribers have requested support for a solution for apex cnames. See the RT ticket for more details.Long-term