Самое важное на данном этапе - общаться с другими мэйнтейнерами. Напишите письмо в рассылку ports@openbsd.org и спросите, не работает ли кто-то уже над этим портом. Расскажите о своих планах автору программы, для которой вы собираетесь создать порт, а также и проблемах, которые вы, возможно, встретили. Если информация об использованной лицензии неверна, сообщите об этом автору. Если процесс портирования и сборки порта этой программы показался вам слишком муторным, подскажите автору, что можно улучшить или исправить. Если он занимается разработкой только для Linux и, кажется, его вообще не интересует остальной мир UNIX, попытайтесь объяснить ему почему он ошибается. Возможно он изменит свои взгяды.
Общение и есть та самая разница, между удачным процессом портирования и поддержкой порта, и тем портом, который в итоге будет забыт.
Во-первых, ознакомтесь с информацией на этой странице. Тестируйте, потом протестируйте еще раз и наконец протестируйте еще разок!
OpenBSD полностью поддерживает обновления. Это означает, что некоторые вопросы должны быть приняты во внимание.
Отправте (submit) порт. Создайте тарбол, содержащий все необходимое для порта. Затем вы можете либо разместить его на общедоступном HTTP-сервере, отправив его URL-адрес на ports@openbsd.org, либо отправить на тот же адрес MIME encoded порт.
Портирование новых программ требует усилий и времени. Поддерживать их в последствии еще сложнее. Вполне реально портировать ту или иную программу, но позволить кому-то другому заниматься поддержкой порта впоследствии. Также можно помогать другим участникам сообщества обновлять и поддерживать свои порты, если общение между вами поможет избежать повторения одной и той же работы.
В культуре OpenBSD сообщества гордое звание MAINTAINER обозначает
в первую очередь ответственность, но никак не статус.
У нас есть CVS с историей комментариев, где упоминается человек, сделавший работу
и заслуживающий уважения.
MAINTAINER порта - это нечто иное: человек, который берет на себя
ответственность за работу порта и готов потратить некоторое время на то, чтобы
он работал как можно лучше.
/usr/ports/,
pick a primary category for your port.
Create a new directory below /usr/ports/<category>/
or /usr/ports/mystuff/<category>/ and create the basic
infrastructure there.
Copy the template Makefile from
/usr/ports/infrastructure/templates/Makefile.template.
Fill in CATEGORIES with the primary category you have chosen.
EXTRACT_SUFX if it's anything besides .tar.gz.
Other examples are .tar.Z, or .tgz.
DISTNAME with the name of the file minus the extract
suffix.
If you have foo-1.0.tar.gz, DISTNAME is
foo-1.0.
SITES with a list of URLs to the locations where
the distfile is kept, https://ftp.openbsd.org/pub/OpenBSD/distfiles/ for
example.
Don't forget the trailing slash.
Try to have at least three distinct sites as well.
Place the most easily accessible first as they are traversed in order.
${SITES}${DISTNAME}${EXTRACT_SUFX}.
All three are used.
Don't set DISTNAME to point to the file directly.
make makesum.
For more complex ports, you have more options and tools available to you:
PATCHFILES available.
This is a list of vendor (not OpenBSD) patches to the port.
Common uses are things like security or reliability fixes which are
occasionally distributed as a patch rather than a full release.
/usr/ports/infrastructure/db/network.conf.
Set SITES to ${SITE_GNU}, or
${SITE_SOURCEFORGE}, etc.
To simplify this process, use the construct
${SITE_FOO:=subdir/}
to append the distribution subdirectory.
SITES=https://github.com/acct/project/releases/download/relname/
GH_ACCOUNT, GH_PROJECT, GH_TAGNAME.
GH_COMMIT should be used instead of GH_TAGNAME.
DISTFILES and PATCHFILES should have
clearly visible version numbers:
don't retrieve foo-latest.tar.gz if it is a link to
foo-1.0.5.tar.gz.
File names should not contain just the version number
(1.0.5.tar.gz);
files can be renamed during fetching if necessary, see
bsd.port.mk(5).
If something is only available in an unversioned file, gently ask the
original program author to make such distinctions clear.
In the meantime, if you must use a file like this,
set DIST_SUBDIR to what a reasonable DISTNAME
would be, like foo-1.0.5, such that different, identically named
versions of the distfile do not clash on the distribution file mirrors
or build machines.
DISTFILES and
PATCHFILES to work,
use DIST_SUBDIR to avoid cluttering
DISTDIR (/usr/ports/distfiles by default) too much.
In this case, DIST_SUBDIR must not include version numbers.
When the port is updated to a later version, some distfiles may not
change, but will be refetched if DIST_SUBDIR is changed.
Even if all distfiles change, it is easier for the user to track cruft.
DISTFILES and PATCHFILES don't necessarily come
from the same set of SITES.
Supplementary sites can be defined using suffixes:
DISTFILES.alt = foo-1.0.5.tar.gz
will come from
SITES.alt.
SUPDISTFILES variable.
Targets such as makesum or fetch-all will
fetch those supplementary files that the casual user doesn't need.
distinfo by typing make makesum.
DISTFILES* are usually processed during
make extract.
EXTRACT_ONLY may be used to limit extraction to a subset of files
(possibly empty).
The customary use of this variable is to customize extraction: for instance,
if some DISTFILES need some special treatment,
they will be removed from EXTRACT_ONLY
and handled manually at post-extract stage.
For historic reasons,
make extract does set up the working directory
first along with extracting files.
Thus, providing a pre-extract or do-extract target is
highly unusual (and fairly suspicious behavior, indicative of a high degree of
obfuscation in the port).
DISTFILES,
and removed from EXTRACT_ONLY, for historic reasons.
make extract.
Pay attention to where the base of the sources are.
Usually, it's /usr/ports/pobj/${PKGNAME}${FLAVOR_EXT}/${DISTNAME}.
You may need to modify the Makefile's WRKDIST variable
if it is different.
PERMIT_* values in the Makefile.
PERMIT_PACKAGE
tells us whether we can put the package on the mirrors.
PERMIT_DISTFILES
tells us whether we can mirror the distfiles.
If both are permitted, simply set PERMIT_PACKAGE=Yes.
Otherwise, set each variable to either Yes or a comment
string indicating the reason distribution is not allowed.
Pay attention to any special conditions you may need to fulfill later on.
For example, some ports require installing a copy of the license.
We recommend you place the license in
/usr/local/share/doc/<name>/.
In addition to the PERMIT_* values, put a license marker like
# License above them as a comment, this way we know why the
PERMIT_* values are set the way they are.
For GPL, specify which version is applicable e.g. "GPLv2 only",
"GPLv2+" (meaning "v2 or newer"), "GPLv3 only", etc.
Makefile and/or create the
configuration script.
./configure --help to see what
options are available.
In particular, look for optional dependencies which may not be present
on your system, but might be picked up on another system or in a bulk
build.
--option flags to the CONFIGURE_ARGS parameter in the
Makefile.
CONFIGURE_ARGS+= to append to the variable.
CONFIGURE_ARGS= will overwrite it.
make build.
cd `make show=WRKSRC` ; cp foo/bar.c{,.orig.port}
foo/bar.c to fix the error.
cd - ; make update-patches
patches/patch-foo_bar_c with your modifications.
make clean patch.
This will delete the work directory, re-extract, and patch your port.
make build, edit source code,
generate a patch using
make update-patches and make clean patch.
patches/ and should be named patch-*
with * being something meaningful.
The preferred naming is patch-FILENAME, where FILENAME
is the name of the file it is patching.
(make update-patches does this automatically for you.)
PATCHFILES is the first half of the
make patch stage.
It can be invoked separately as make distpatch,
which is a convenient target for porters.
Ignore this if you haven't set it.
make update-patches to generate patches.
${WRKDIST}.
-kk to avoid this.
SEPARATE_BUILD.
CONFIGURE_STYLE=gnu can).
Makefile.
To repeat issue the command make clean configure.
Configuration files will usually be installed somewhere under
/usr/local and handled by
pkg_add(1)
@sample annotations.
After a package has been installed the contents of pkg/MESSAGE will
be displayed if it exists.
The OpenBSD file locations are:
user executables: /usr/local/bin system admin executables: /usr/local/sbin program executables: /usr/local/libexec libraries: /usr/local/lib architecture dependent data: /usr/local/lib/<name> installed include files: /usr/local/include or /usr/local/include/<name> single-machine data: /etc or /etc/<name> local state: /var/run games score files: /var/games GNU info files: /usr/local/info man pages: /usr/local/man/... read-only architecture-independent: /usr/local/share/<name> misc documentation: /usr/local/share/doc/<name> examples files: /usr/local/share/examples/<name>
COMMENT in Makefile.
COMMENT is a SHORT one-line description of the port (max. 60
characters).
Do NOT include the package name (or version number of the software) in
the comment.
Do NOT start with an uppercase letter unless semantically significant,
and do NOT end with a period.
DON'T EVER START WITH AN INDEFINITE ARTICLE SUCH AS "a" or "an" - remove
the article altogether.
The main usage of COMMENT is the one-liner from
pkg_info(1):
py3-cairo-1.24.0 cairo bindings for Python
pkg/DESCR.
One to a few paragraphs concisely explaining what the port does is sufficient.
Lines should be no longer than 80 characters.
This can be done by first editing the DESCR file
and then running it through fmt.
/usr/ports/infrastructure/db/user.list for your port to
use and don't forget to include that file in your commit.
make fake.
Libraries should never be stripped.
Executables are stripped by default, unless you set
DEBUG_PACKAGES; this is governed by
${INSTALL_STRIP}.
${INSTALL_PROGRAM} honors this automatically and is preferable to
unconditional stripping (e.g., by an install-strip target or by
running strip from the Makefile).
You can use objdump --syms to determine if a binary is stripped or
not.
Stripped files have no symbols in the SYMBOL TABLE.
/etc/mtree directory is up to date.
(The next step uses the mtree lists to remove existing directories from
generated packing-lists). Remember that the OpenBSD
(U)pdate does not touch /etc...
For automatic updating of /etc,
sysmerge(8) may help.
pkg/PLIST.
After the installation with make fake is complete, use the
developer's command make update-plist, which creates or updates
the file PLIST in the pkg directory.
This file is a candidate packing list.
Peruse PLIST and verify that everything was installed and that it
was installed in the proper locations.
Anything not installed can be added to a port Makefile
post-install rule.
Note that PLIST annotations are documented in the
pkg_create(1) manual,
and that
update-plist(1)
is also documented.
PLIST
as they've been installed by a dependency;
if you added to LIB_DEPENDS or RUN_DEPENDS,
run make update-plist to remove these.
make package, test installation of the
resulting package with make install, and test its removal with
make uninstall.
When dealing with multi-packages, it may instead be convenient to use
pkg_add(1) and
pkg_delete(1) directly,
setting TRUSTED_PKG_PATH to
/usr/ports/packages/%a/all/ in the environment.
*DEPENDS, and nothing more.
Check names, particularly in the make configure stage, for hidden
dependencies (stuff that exists elsewhere in the ports tree and might be
detected if the user installs some other ports first).
make port-lib-depends-check and add every
LIB_DEPENDS or WANTLIB annotation that is needed
until it runs cleanly.
You may want to read the update guidelines to
understand why this is so important.
NO_TEST=Yes if a port has no test infrastructure.
If dependencies are required to run the tests, but not to build the port,
list them in TEST_DEPENDS.
Please note: do not set NO_TEST if a port has an empty regression
test infrastructure.
make clean succeeds.
Sometimes the make fake stage creates files in the build directory
which will cause this to fail.
/usr/ports/infrastructure/bin/portcheck utility
in your port directory and take care of problems it finds, if any.
Try to get others to test it on a variety of platforms for you.
sizeof(int) != sizeof(long) on this platform.
If you are not a developer with CVS access, then you will have to find an OpenBSD developer to do the following steps for you (ask on ports@openbsd.org).
Before you import anything, get at least one "OK" from another ports developer (the more the better).
If using @newuser or @newgroup in the PLIST files,
check that no users were added to
/usr/ports/infrastructure/db/user.list since the port was created.
For new ports we use cvs import, rather than adding new files
individually.
For example, to import a new lang/kaffe1 port, first do a dry-run
import:
$ cd /usr/ports/lang/kaffe1 $ cvs -ndcvs.openbsd.org:/cvs import ports/lang/kaffe1 username username_yyyymmddWhere
username is your account username,
and yyyymmdd is the current date.
If this succeeds, then you can remove -n to import for real.
Your editor will be invoked so that you can enter a commit message.
In the commit message, at least state what you are importing and which
developers provided OKs.
Make sure the import path is correct; it always starts with ports/.
Alternatively, you can use ports/infrastructure/bin/portimport to
import new ports.
Makefile, e.g., for ports/lang/kaffe1,
add it to ports/lang/Makefile.
Don't forget to commit any changes made to
/usr/ports/infrastructure/db/user.list.
sqlports package includes
show-reverse-deps, making it trivial to know the full
tree of ports that depend directly or indirectly on a given port.
In case of problems, communicate with the maintainers of such ports.
Likewise, be alert for dependency updates, and check that the maintainer
did their job.
make update-plist.
Use make port-lib-depends-check to see what libraries your
software needs
(that will end up in LIB_DEPENDS or WANTLIB, usually).
Identify various files and binaries in the dependencies that have to be present
for the port to work.
By this point, you should have a fair understanding of your port's working.
PERMIT* stuff.
As a rule, even if a dependency is very small, if it affects the licensing of
the resulting package, you will have to explicitly take care of it.
Considering all possible options, you should be left with a much smaller set of options for your port, mostly depending on what packages are needed to run the software. For now, do not worry about build dependencies. Remember that the OpenBSD ports system is focused on the end user, and the end user will want to install binary packages, so it doesn't matter if you need a huge piece of software to build your port if it doesn't show up as a library or runtime dependency.
MULTI_PACKAGES и PSEUDO_FLAVORS
In this case, try setting the MULTI_PACKAGES variable to a list of
-sub packages, add corresponding COMMENTS,
and look at your packaging.
Basically, MULTI_PACKAGES only affects the packaging: if you have
MULTI_PACKAGES=-s1 -s2 all stuff relevant to the package will exist
in two variants:
COMMENT-s1 for the first package,
COMMENT-s2 for the second package,
PLIST-s1, PLIST-s2,
DESCR-s1, DESCR-s2.
You need to write those COMMENT-s1 and COMMENT-s2
in the Makefile, split your PLIST into two parts,
and create DESCR-s1/DESCR-s2.
It is a good idea to start with the minimal framework work required:
just copy the existing description and comments, because you will have
to fiddle with MULTI_PACKAGES and stuff before you polish this.
Once you've separated the files properly, you will need to check dependencies:
LIB_DEPENDS, WANTLIB, and RUN_DEPENDS
will be split for each subpackage.
It is usually time to check that your multi-packaging "works," and that
those nasty dependencies you don't want to force on the user are indeed
relegated to a specific subpackage.
Assuming everything works, you're mostly done. Just pick reasonable names for the various packages, and fill in the comments and descriptions. The end-user will be able to just install the package(s) they want.
But wait.
What about the build, you say?
Well, having a lot of dependencies during build is not a problem.
Most packages are built by the OpenBSD team using special build runs (known
as bulk builds) where a developer just builds all possible packages on a
dedicated machine (or several, for slow architectures).
Since everything will get built, having big dependencies is not an issue.
Building the same thing several times, is an issue, though, which is why
MULTI_PACKAGES are the best way to handle options (when possible):
one build, one set of packages to test, better quality overall...
If you also want to help people who build packages themselves, you may consider
adding PSEUDO_FLAVORS.
A pseudo-flavor is a way to tweak an option (say, disable the graphical
interface) that's very similar to actual flavors.
In fact, the biggest difference is a functional difference: a pseudo flavor
should only affect the set of packages that get built, but it is never
allowed to modify the actual package contents.
For instance, assuming you separated the graphical interface into a separate
subpackage (MULTI_PACKAGES=-main -x11), you could create a pseudo
flavor no_x11 that avoids building the -x11 subpackage.
The crucial point is that this flavor should NOT affect the -main package
in any way.
You would end up with a Makefile that looks something like this:
COMMENT-main = foo core application
COMMENT-x11 = foo graphical interface
V = 1.0
DISTNAME = foo-$V
CATEGORIES = app
MULTI_PACKAGES = -main -x11
PSEUDO_FLAVORS = no_x11
FLAVOR ?=
WANTLIB = c m crypto ssl
WANTLIB-x11 = ${WANTLIB} X11 Xt
RUN_DEPENDS-x11 = ${BASE_PKGPATH},-main>=$V
CONFIGURE_STYLE = gnu
.include <bsd.port.arch.mk>
.if !${BUILD_PACKAGES:M-x11}
CONFIGURE_ARGS += --disable-x11
.endif
.include <bsd.port.mk>
Notice that you only have to write a very small conditional section in the
Makefile:
the system doesn't care at all that you define extra variables.
MULTI_PACKAGES setups used to be asymmetric,
with a -main subpackage and other subpackages,
with the -main subpackage always built,
and other subpackages possibly depending upon it.
The current situation is totally symmetric: any subpackage can depend on any
other.
The infrastructure has specific provisions to avoid looping indefinitely.
The infrastructure takes special care of library inter-dependencies:
it can detect which WANTLIB come from external dependencies,
and which come from inter-dependencies.
While external LIB_DEPENDS and WANTLIB are checked at
the start of build, LIB_DEPENDS and WANTLIB that
refer to one of the subpackages currently being built
will only be checked at packaging time
(and thus packages may be created in a specific order to satisfy
interdependencies).
The infrastructure provides specific variables to help in writing
inter-dependencies:
BUILD_PKGPATH contains the PKGPATH used
during building the current packages, taking flavors and pseudo-flavors into
account.
It is highly recommended to use this variable instead of rolling your own:
failure to do so will often trigger rebuilds in interesting flavors situations.
For instance:
... FLAVORS = a b FLAVOR ?= MULTI_PACKAGES = -p1 -p2 WANTLIB-p1 = foo LIB_DEPENDS-p1 = some/pkgpath,-p2 ...If you go on and build in some/pkgpath with
FLAVOR=a,
then creating the subpackage for -p1
will trigger a rebuild with FLAVOR=''.
You would instead write:
LIB_DEPENDS-p1 = ${BUILD_PKGPATH},-p2
There is also a BASE_PKGPATH variable, which does not take
pseudo-flavors into account.
This variable has limited applicability: it corresponds to a transition between
old MULTI_PACKAGES and newer ones, where the old main
subpackage did not have any marker in its pkgpath, and thus the corresponding
package needs a @pkgpath ${BASE_PKGPATH} in its packing-list.
(In general, pseudo-flavors are build information, and should not make their
way into packages and packing-lists).
FLAVORS и PKGNAMESMakefile: those flavors will
command some configuration options,
and usually additions to various dependencies.
Note that package naming is mostly automatic: the PKGNAME will have
an extension built by appending the specified flavors to its name.
So, if
PKGNAME = foo-1.0 FLAVORS = f1 f2 f3and you build the port with
FLAVOR='f3 f1', then
FULLPKGNAME=foo-1.0-f1-f3 (FLAVORS is used to reorder
specified flavors in a canonical way).
There are sometimes mixed situations, where some packages do depend on the
FLAVOR, and some don't.
For instance, some ports include a large set of documentation that does not
depend on the FLAVOR, and some actual programs that depend on the
FLAVOR.
In such cases,
you can specify the FULLPKGNAME for the documentation
subpackage explicitly.
Something like this:
CATEGORIES = app
COMMENT-core = foo application
COMMENT-doc = foo documentation
V = 1.0
DISTNAME = foo-1.0
PKGNAME-core = foo-$V
FULLPKGNAME-doc = foo-doc-$V
FLAVORS = crypto
MULTI_PACKAGES = -core -doc
WANTLIB-core = c m
.if ${FLAVOR:L:Mcrypto}
WANTLIB-core += ssl crypto
CONFIGURE_ARGS += --enable-crypto
.endif
As mentioned in the documentation, all package names have the same structure:
stem-version-flavor_extension.
By default, packages with the same stem do conflict, and update paths will
look at candidates with the same stem.
The right package will be the one coming from the exact same
PKGPATH,
or matching @pkgpath annotation in the packing-list.
Usually, MULTI_PACKAGES should not conflict, so they must have
different names (and the infrastructure has no way to build those names).
On the other hand, flavors should conflict, and thus have the same name.
The flavor information should end at the end of the package name, except for
pseudo-flavors, which do not change the way a package is built.
As far as dependencies go, by default,
specifying a PKGPATH will just
create a stem-* dependency, meaning any package with the right stem
will match the dependency.
By default, any flavor will match.
If only specific flavors are desired, you must include them in your
specification, e.g., stem-*-flavor.
If some flavors are unwanted, you can remove them from matching packages,
e.g., stem-*-!flavor.
Since OpenBSD 4.9, asking for at least some version of a dependency can be
directly tacked to the PKGPATH, e.g., dir/foo>=2.0.
pkg_add -u,
the system will replace each package with a new version,
one package at a time.
So the user will run a mixed system, even if it is for just a few minutes.
There are basically two update models of which maintainers must be aware.
You should note that part of the update process, especially the macroscopic changes for users who update every six months, is not yet automated. The global update mechanism is still a work in progress, and pkg_add will be able to cope with more issues in the future. As of now, you should focus on making sure the system updates correctly, one port at a time, and that one port's update takes other ports into account, as far as conflicts and other issues are concerned.
${WRKBUILD}/shared_libs.log verbatim as a basis for your
SHARED_LIBS setup.
This will help during updates.
PLIST_REPOSITORY is set by default and will build a
database of packing-lists as packages are built on your system.
This is useful to find out about forgotten package name bumps, and also
to check for conflicts with older packages.
RUN_ and LIB_DEPENDS will be satisfied by
any version of a package.
Do not insist on a given version unless you have to. Use minimal versions
whenever possible.
HOMEPAGE, MAINTAINER
or description changes,
changes to patches or build flags.
If the upstream version has not changed, the package name bump is done
by incrementing REVISION if already present, otherwise adding
REVISION = 0 towards the top of the Makefile.
If MULTI_PACKAGES are used, increment REVISION
to set the default revision for all subpackages, or increment the
individual REVISION-subpkg as necessary (this overrides
REVISION).
If in doubt, use make show=PKGNAMES to check before and after
making changes.
EPOCH to make sure pkg_add(1) sees
the package as a newer package.
This will add v${EPOCH} to FULLPKGNAME to form a full
package-name conforming to
packages-specs(7).
0.1 < 0.1p0 < 0.2 < 0.1v0 < 0.1p0v0 < 0.2v0 < 0.1v1.
Also additional words including beta, rc and
pre are handled.
See packages-specs(7)
for more detailed information, and use
pkg_check-version(1)
to check the ordering of version numbers.
make patch
to have an initial copy of the port before the update.
Makefile to grab the new version, run
make makesum and make patch as a starting basis.
shared_libs.log to check
whether the software authors did significant changes.
Note well that this is not enough.
Many software authors do not really understand shared library issues.
You have to read the full diff between the old and the new version, and bump
library versions accordingly.
When in doubt, bump the major version.
pkg_add -u, make sure
they are visible in the package.
When your packaging policy changes, document it in the package description.
For instance, if you move the documentation into a separate package for
space constraints, the main package description should mention that the
documentation is now available as a separate package.
cvs add to add any new files.
cvs rm to remove files that are no longer needed
(e.g. upstreamed patches).
cvs -n up -d.
New files should be marked A, deleted files should be marked
D, and changed files should be marked M.
Look for files marked ? - did you mean to cvs add
them?
cvs commit.
When invoking cvs commit,
you can either list the files individually,
or if you provide no filenames, CVS will recursively commit (be careful with
this feature).
You will be asked to enter a commit message, in which you should state which
port is being updated, and who provided an OK.
/usr/local/etc/rc.d.
/usr/local is often shared between several machines, thanks to NFS.
For this reason, configuration files that are specific to a given machine
can't be stored under /usr/local.
/etc is the central repository for per machine configuration files.
Moreover, OpenBSD policy is to never update files under /etc
automatically.
Ports that need some specific boot setup should advise the administrator
about what to do instead of blindly installing files.
-lcrypt, -ldl, or -lrt.
The functions provided by these libraries are part of libc.
The crypt() function does not support DES, only bcrypt.
/usr/ports/infrastructure/db/user.list for details.
strcat/strcpy/strcmp/sprintf.
In general, sprintf should be replaced with snprintf.
/tmp with symbolic links to more strategic
files, such as /etc/master.passwd.
fopen and freopen
create a new file or open an existing file for writing.
An attacker may create a symbolic link from /etc/master.passwd to
/tmp/addrpool_dump.
The instant you open it, your password file is hosed.
Yes, even with an unlink right before.
You only narrow the window of opportunity.
Use open with O_CREAT|O_EXCL
and fdopen instead.
mktemp function.
Heed the warnings of the bsd linker about its uses.
These must be fixed.
This is not quite as simple as s/mktemp/mkstemp/g.
Refer to mktemp(3) for more
information.
Correct code using mkstemp includes the source to
ed or mail.
A rare instance of code that uses mktemp correctly can be found in
the rsync port.
startx problem.
As a setuid program, you could launch startx with any file as a script.
If the file was not a valid shell script, a syntax error message would
follow, along with the first line of the offending file, without any
further permission check.
Pretty handy to grab the first line of a shadow passwd file, considering
these often start with root entry.
Do not open your file, and then do an fstat on the open descriptor
to check if you should have been able to open it (or the attacker will play
with /dev/rst0 and rewind your tape) -- open it with the correct
uid/gid/grouplist set.
popen and system.
Use fork, pipe and execve instead.
/dev/fd/0.
xkobo port for an instance of such a change.
PATH (never use
system with an unqualified name, avoid execvp),
but also more subtle items such as your locale, timezone, termcap, and so on.
Be aware of transitivity: even though you're taking full precautions,
programs you call directly won't necessarily.
Never use system in privileged programs, build your command
line, a controlled environment, and call execve directly.
The perlsec man page is a good tutorial on such problems.
issetugid addresses this problem, from the library writer
point of view.
Don't try to port libraries unless you understand this issue thoroughly.
arc4random is used instead.
If the deterministic (i.e: repeatable) behavior must be preserved, use the
OpenBSD extensions:
srand_deterministic, srandom_deterministic,
srand48_deterministic, seed48_deterministic
and lcong48_deterministic.
__OpenBSD__ should be used sparingly, if at all.
Constructs that look like
#if defined(__NetBSD__) || defined(__FreeBSD__)are often inappropriate. Don't add blindly
__OpenBSD__ to it.
Instead, try to figure out what's going on, and what actual feature is needed.
Manual pages are often useful, as they include historic comments, stating when
a particular feature was incorporated into BSD.
Checking the numeric value of BSD against known releases is often
the right way.
See the
NetBSD pkgsrc guide
for more information.
BSD is a bad idea.
Try to include sys/param.h.
This not only defines BSD, it also gives it a proper value.
The right code fragment should look like:
#if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif
tcgetattr works
than whether you're running under BSD 4.3 or later, or SystemVR4.
These kind of tests just confuse the issue.
The way to go about it is, for instance, to test for one particular system,
set up a slew of HAVE_TCGETATTR defines, then proceed to the next
system.
This technique separates features tests from specific OSes.
In a hurry, another porter can just add the whole set of -DHAVE_XXX
defines to the Makefile.
One may also write or add to a configure script to check for that feature and
add it automatically.
As an example not to follow, check nethack 3.2.2 source: it assumes loads of
things based on the system type.
Most of these assumptions are obsolete and no longer reflect reality: POSIX
functions are more useful than older BSD versus SystemV differences, to the
point that some traditional bsd functions are now only supported through
compatibility libraries.
#define POSIX_C_SOURCE
throughout the whole project, not when you feel like it.
unistd.h, fcntl.h or termios.h.
The man page frequently states where the prototype can be found.
You might need another slew of HAVE_XXX macros to procure the right
file.
Don't worry about including the same file twice; include files have guards
that prevent all kinds of nastiness.
If some broken system needs you to write the prototype, don't impose on all
other systems.
Roll-your-own prototypes will break because they may use types that are
equivalent on your system, but are not portable to other systems
(unsigned long instead of size_t), or get some
const status wrong.
Also, some compilers, such as OpenBSD's own gcc, are able to do a better job
with some very frequent functions such as strlen if you include the
right header file.
implicit declaration of function foo() indicates that a function
prototype is missing.
This means that the compiler will assume the return type to be an integer.
Where the function actually returns a pointer, on 64-bit platforms it will
be truncated, usually causing a segmentation fault.
/* prototype part */
#ifdef USE_OWN_GCVT
char *foo_gcvt(double number, size_t ndigit, char *buf);
#else
/* include correct file */
#include <stdlib.h>
/* use system function */
#define foo_gcvt gcvt
#endif
/* definition part */
#ifdef USE_OWN_GCVT
char *foo_gcvt(double number, size_t ndigit, char *buf)
{
/* proper definition */
}
/* typical use */
s = foo_gcvt(n, 15, b);
bsd.port.mk set the installer's path.
Specifically,
they set /usr/bin and /bin to be searched
before /usr/local/bin and /usr/X11R6/bin.
bsd.port.mk,
as people are supposed to update their whole ports tree,
including bsd.port.mk.
update-plist to generate and update packing-lists
instead of doing things manually.
You can comment unwanted lines out with @comment.
update-plist can detect most file types and copy most extra
annotations correctly.
It is not infallible; review the changes it makes.
Check they make sense, and check if any new example configuration files should
be followed by
@sample annotations.
curses.h/libcurses/libtermlib is the "new curses."
Change:
ncurses.h ==> curses.h
_USE_OLD_CURSES_ before
including curses.h (usually in a Makefile) and linking with
-locurses.
sgtty to the newer POSIX tcgetattr family.
Avoid the older style in new code.
Some code may define tcgetattr to be a synonym for the older
sgtty, but this is at best a stopgap measure on OpenBSD.
The xterm source code is a very good example of what not to do.
Try to get your system functionality right: you want a type that remembers
the state of your terminal (possible typedef), you want a function that
extracts the current state, and a function that sets the new state.
Functions that modify this state are more difficult, as they tend to vary
depending upon the system.
Also, don't forget that you will have to handle cases where you are not
connected to a terminal, and that you need to handle signals: not only
termination, but also background (SIGTSTP).
You should always leave the terminal in a sane state.
Do your tests under an older shell, such as sh, which does not reset the
terminal in any way at program's termination.
TERMCAP variable
and get it to work properly.
sigaction to ensure a specific semantics,
along with other system calls referenced in the corresponding man page.