scsitape / stenc Goto Github PK

SCSI Tape Encryption Manager - stenc (formerly on https://sourceforge.net/projects/stenc/)

License: GNU General Public License v2.0

Makefile 0.12% Shell 0.02% C++ 99.60% M4 0.26%

backup scsi encryption aes-256 aes-128 aes tape lto linux aix lto-tape-drives encryption-management ssp hardware key-descriptors

stenc's Introduction

Stenc

SCSI Tape Encryption Manager - Manages hardware encryption on LTO tape drives (starting with generation 4). Program should work on any other SCSI security protocol (SSP) capable tape drives. Supports key change auditing and key descriptors (uKAD).

Features

SCSI hardware-based encryption management
Supports Linux and FreeBSD
Supports most SSP compliant devices, such as LTO-4 tape drives
Key change audit logging
AES Encryption
Key Descriptor Management

Get the source code and compile

git clone https://github.com/scsitape/stenc.git
cd stenc/
autoreconf --install
./autogen.sh && ./configure  
make check     # optionally run the catch testing framework
make

Usage example

$ stenc -f /dev/nst0
Status for /dev/nst0 (TANDBERG LTO-6 HH 3579)
--------------------------------------------------
Reading:                         Decrypting (AES-256-GCM-128)
Writing:                         Encrypting (AES-256-GCM-128)
                                 Protecting from raw read
Key instance counter:            1
Drive key desc. (U-KAD):         mykey20170113
Supported algorithms:
1    AES-256-GCM-128
     Key descriptors allowed, maximum 32 bytes
     Raw decryption mode allowed, raw read enabled by default

Linux Packages

Requirements

AIX support was suspended on 2022-05-08 until we have contributors who can develop and test the code on AIX.

License

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

stenc's People

Contributors

Stargazers

Watchers

Forkers

marianrh malvineous josefmeixner jonasstein unipartdigital c3rberus svalx michaelburge sandrogithub jmwilson christianreiss pwntester asukaryuko imsar-it protarios

stenc's Issues

Invalid argument (Invalid IOCTL call) when using lin_tape device driver? (RHEL9 & ULT3580-HH8)

Hello,

I am using IBM TS4300 Tape Library (LTO8 FC) library, this is zoned to a RHEL 9.3 Linux host, the ULT3580-HH8 tape drive is detected in the system. Installed lin_tape device driver.

# cat /proc/scsi/IBMtape
lin_tape version: 3.0.66
lin_tape major number: 511
Attached Tape Devices:
Number  model       SN                       HBA                       SCSI            FO Path
0       ULT3580-HH8 1174F0805B               qla2xxx                   7:0:2:0         NA

# rpm -qi lin_tape
Name        : lin_tape
Version     : 3.0.66
Release     : 1
Architecture: x86_64
Install Date: Thu 15 Feb 2024 02:39:41 PM
Group       : System Environment/Kernel
Size        : 1735657
License     : GPL
Signature   : (none)
Source RPM  : lin_tape-3.0.66-1.src.rpm
Build Date  : Thu 15 Feb 2024 02:38:14 PM
Packager    : IBM Tape SCSI Device Driver Development
Vendor      : IBM
Summary     : IBM Tape SCSI Device Driver for Linux
Description :

# rpm -qi lin_taped
Name        : lin_taped
Version     : 3.0.66
Release     : 1
Architecture: x86_64
Install Date: Thu 15 Feb 2024 02:40:59 PM
Group       : System Environment/Kernel
Size        : 179136
License     : Proprietary
Signature   : (none)
Source RPM  : lin_taped-3.0.66-1.src.rpm
Build Date  : Mon 28 Aug 2023 09:29:31 AM
Packager    : IBM Tape SCSI Device Driver Development
Vendor      : IBM
Summary     : IBM Tape SCSI Device Driver Application/Daemon

I have installed the IBM Tape SCSI Device Driver for Linux (lin_tape), and I can write/read to the device using tar.

However, when I try to use stenc to check status, I get an error.

# stenc --v
stenc 2.0.0 - SCSI Tape Encryption Manager

# stenc -f /dev/IBMtape0
stenc: Invalid argument

# dmesg
[14164.410790] lin_tape: lin_tape_drive_ioctl invalid ioctl

# cat /var/log/lin_tape.trace
IBMtapeDevDriver  Thu Feb 15 19:00:13 2024
   lin_tape_open: Attempt to open IBMtape0
   IBMtape0 opened
   lin_tape_close: Attempt to close IBMtape0
IBMtape0-----0805B  Thu Feb 15 19:00:13 2024
   Tape device opened
   lin_tape_drive_ioctl: Invalid IOCTL call
   Tape device closed.

I also tried compiling stenc with debug flag, there was no extra output observed.

# ./autogen.sh && ./configure --with-scsi-debug && make
# sg_raw -r 44 /dev/IBMtape0 a2 00 00 00 00 00 00 01 00 00 00
do_scsi_pt: Invalid argument

My goal is to be able to use stenc to enable tape encryption.... Anyone have any idea on what could be going on?

The same tape library is zoned to an AIX Power9 system using an older build of stenc, no issues there.

I am thinking something with RHEL 9.3 and the lin_tape driver? I did observe that when lin_tape is installed the way the device appears in /dev changed, no longer /dev/st0 and instead /dev/IBMtape.

Let a codechecker run on the source

We should do some computer aided code tests.
Everybody can contribute here.

Test code needed

It would be great to have some test code.
Perhaps googletest framework?

Provide example key file

so that the user can see the data format.

warning: The preprocessor macro `STDC_HEADERS' is obsolete.

autoreconf --install
configure.ac:15: warning: The preprocessor macro `STDC_HEADERS' is obsolete.
configure.ac:15:   Except in unusual embedded environments, you can safely include all
configure.ac:15:   ISO C90 headers unconditionally.

The manpage is not up to date

Due to the changes made by #82, the manpage should be updated.

Can we delete the last check in the .yml file?

In https://github.com/scsitape/stenc/blob/master/.github/workflows/c-cpp.yml we have


    - name: make check
      run: make check
    - name: make distcheck
      run: make distcheck

two times. Can we delete the last one, or has it to be there?

Compilation error

OS: Fedora 36 x86_64
g++ --version
g++ (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)

$ LANG=C make
make  all-recursive
make[1]: Entering directory '/home/pawel/stenc'
Making all in src
make[2]: Entering directory '/home/pawel/stenc/src'
depbase=`echo main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I..    -std=c++17   -g -O2 -MT main.o -MD -MP -MF $depbase.Tpo -c -o main.o main.cpp &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo scsiencrypt.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I..    -std=c++17   -g -O2 -MT scsiencrypt.o -MD -MP -MF $depbase.Tpo -c -o scsiencrypt.o scsiencrypt.cpp &&\
mv -f $depbase.Tpo $depbase.Po
scsiencrypt.cpp: In function 'std::unique_ptr<const unsigned char []> scsi::make_sde(encrypt_mode, decrypt_mode, uint8_t, std::vector<unsigned char>, const std::string&, sde_rdmc, bool)':
scsiencrypt.cpp:236:28: error: cannot convert 'scsi::sde_rdmc' to 'std::byte' in initialization
  236 |   page.flags |= std::byte {rdmc};
      |                            ^~~~
      |                            |
      |                            scsi::sde_rdmc
make[2]: *** [Makefile:366: scsiencrypt.o] Error 1
make[2]: Leaving directory '/home/pawel/stenc/src'
make[1]: *** [Makefile:357: all-recursive] Error 1
make[1]: Leaving directory '/home/pawel/stenc'
make: *** [Makefile:298: all] Error 2

clarify st0/nst0

the tool answers with /dev/nst0 but the manpage uses st0 in examples and somewhere it says one should always use nonrewinding devices. How does that match?

New IBM LTO8 drive firmware returns 0x24 error

This looks like issue #11 but is different (this error code is 0x24 vs issue 11's 0x26).

Latest (as of May 3 2022) stenc works fine with an IBM Ultrium-TD8 drive with J4D0 and JAYE firmwares; but with the latest N4Q0 firmware, stenc returns an error:

$ sudo ./stenc -f /dev/nst0 --detail
Status for /dev/nst0
--------------------------------------------------
Device Mfg:              IBM
Product ID:              ULTRIUM-TD8
Product Revision:        N4Q0
Sense Code:              Illegal Request (0x05)
 ASC:                    0x24
 ASCQ:                   0x00
 Additional data:        0x00000c01504230303030340000000abb00000001080080a2704c38000000040000000000000000000000000000000000000000000000000000000000000000000000000054314d5930484756444100000000000000000000

Per IBM's doc at https://www.ibm.com/docs/en/ts3500-tape-library?topic=information-sense-key-illegal-request , ASC 0x24 and ASCQ 0x00 means "Invalid Field in CDB". Not sure if this means the data structure's the wrong length or what; I'll continue to do investigating on my end to see if I can work out what the drive needs with this firmware, but wanted to open this issue in case others can help take a look.

Also in case it helps, here's the link to IBM's fixlist showing what's changed between J4D0/JAYE firmwares and the latest N4Q0 firmware: https://delivery04.dhe.ibm.com/sar/CMA/STA/09qkh/0/LTO8_N4Q0_fixlist.txt

man page REPORTING BUGS

How to continue with REPORTING BUGS section in man?
Keep / drop / add github issues

Use machine independent datatypes

substitute machine dependent datatypes like int with fixed ones like uint64_t
This is not difficult but we should have some tests first.

#include <cstdint>
std::uint64_t mycounter;

Line break in key file // rewrite read key function in proper c++

make proper Unix line breaks in the key file.
Affects key generator and probably the code, where the key is read.

Update packages in distributions to 1.1.1

Gentoo Done
Debian @berkovskyy, could you have a look at Debian packages, please?
openSuSE @svalx, could you have a look at openSuSE packages, please?
AUR

List new dependencies in changelog

Add all (not standard lib) dependency changes towards 2.0 in the changelog for distributors.

License information in SPDX standard

The project should add license information for each file according to the spdx standard.
There is a tool, which will can help us:
https://reuse.software/faq/

add license badge
clearify licenses where it is not clear
add license information with reuse for source code
add license information with reuse for other files
add CI compliance check https://github.com/marketplace/actions/reuse-compliance-check

Test the source and report

If you have a supported tape, please test the code and report if it works.
We want to release 1.0.8 soon.

./configure syntax error on line 4556 in CentOS 7.9

Hi Everyone, I have been trying to test YATM in an IBM LTO-8 tape system, which depends on stenc, to work.

Upon trying to run the commands in the README I am facing the following issue and I am not sure how to proceed, anyone have any clue or tips on how to solve this issue?

autoreconf --install or ./autogen.sh don't output any issues.

I believe most packages necessary are on the most recent versions, this is also based on stenc-2.0.0
automake.noarch 1.13.4-3.el7
autoconf.noarch 2.69-11.el7
m4.x86_64 1.4.16-10.el7
bash-completion.noarch 1:2.1-8.el7

My Linux knowledge is somewhat limited so any help would be appreciated here.

`[root@server stenc]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
./configure: line 2654: ]: command not found
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking X usability... no
checking X presence... no
checking for X... no
checking $CC usability... no
checking $CC presence... no
checking for $CC... no
checking -c usability... no
checking -c presence... no
checking for -c... no
checking $CFLAGS usability... no
checking $CFLAGS presence... no
checking for $CFLAGS... no
checking $CPPFLAGS usability... no
checking $CPPFLAGS presence... no
checking for $CPPFLAGS... no
checking conftest.$ac_ext usability... no
checking conftest.$ac_ext presence... no
checking for conftest.$ac_ext... no
checking >&5 usability... no
checking >&5 presence... no
checking for >&5... no
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether to output raw SCSI messages... no
checking your OS... Linux
checking whether to build with static libgcc... no
checking for pandoc... yes
./configure: line 4556: syntax error near unexpected token `BASH_COMPLETION_DIR,'
./configure: line 4556: `PKG_CHECK_VAR(BASH_COMPLETION_DIR, bash-completion >= 2.0, completionsdir,'
`

Testers needed, please enroll

stenc is used on different operating systems and with different hardware.

If you are willing to help as beta tester, please add your details in a reply to this ticket:

githubuser, OS, Architecture, Tapedrive
@jonasstein, Gentoo, amd64, TANDBERG LTO-6 HH

We will ping your nick in future test request issues.

Continuous Integration script

Setup a CI script on github

Can we get AIX binary for 1.0.8?

There is a new 1.0.8 release but no aix7_binary_stenc-1.0.8. Is it possible to attach a binary version for us that don't have access to an AIX box with builds tools. Would be very useful.

Release 1.0.9

I think it should be 1.0.9

stenc/configure.ac

Line 1 in 35b852c

AC_INIT([stenc],[1.0.8])

stenc/configure.ac

Line 18 in 35b852c

AC_CHECK_INCLUDES_DEFAULT

This macro requires autoconf at least version 2.70. Many systems use version 2.69 e.g Fedora 35, CentOS 8 and 9, Ubuntu 20.04.
It compiles without this macro just fine, so it should be removed.

Also the ChangeLog file should be updated.

Consider breaking changes for v2

Follow-up to conversation with @jonasstein. Changing output and logging may be a breaking change, so consider bumping the major version to 2 with additional changes:

changing logging from /var/log/stenc to standardized syslog (see #31) may be considered breaking
review proper destination for informational messages and output (stdout vs stderr)
revise command syntax to be consistent with the mt(1) command - I like moving from stenc -e on to stenc encryption on, and from stenc --details to stenc status

stenc should not move the tape

While investigating #27, I saw in the code if stenc can't determine the encryption status of the current block, it will start moving the tape forward until it gets a different answer, up to some limit. This can happen if the tape is positioned at a file mark or end of tape, which doesn't hold data.

Two things:

requesting status should never change state - just report the information as-is that encryption status can't be determined
should change "Volume encryption" to "Current block encryption" or such for correctness. The actual command in the spec is called "next block encryption status" because all it determines the encryption setting for the record at the current tape head position. Other parts of the volume could be encrypted or not.

need script to set version numbers properly

A little helper script, which updates the version number nicely in all required files would be nice.
Without such a script it calls for a release 2.0 with 1.1 remaining in some files.

Considering C++17 as minimum requirement

We could make the code a lot cleaner with features from C++ 17 or even C++ 20
Which version should we expect?

Seems that even the most important C++ 20 functions have been available since many years in the major compilers:
https://en.cppreference.com/w/cpp/compiler_support

As long we do not use exotic features, it should even be fine to switch to 20. What do you think?
We could also go for 17 now and wait a few years with 20...

I think we should be clear that we are safe to switch to version X and update all tests, documents and Makefiles according to the decision before we merge the PRs with new versions

For example in

grep -R "c89"
INSTALL:     ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix

@ninthclowd and others what do you think?

Get good random numbers externally, or by c++ function/lib but not via OS

To not pull random numbers via OS.

Two possible solutions:

a) Unix philosophy: One tool per task.
we drop the key generation by stenc and just provide a manual with shell commands to generate a secure key and explain how to test the random source.
(see also #3)

b) use a proper C++ library
Also include a parameter, which will send a huge amount of the used random to stdout for test purpose:

# user can test, if his library and random source are working.
$> stenc --test-rnd | entropy_checker
Shannon entropy is 8.8

Wrong version in the configure.ac

stenc/configure.ac

Line 1 in 20edbdc

AC_INIT([stenc],[1.1.0])

It should be 1.1.1

Errors don't display correctly

When an error appears, version 1.0.8 displays:

Sense Code:              Illegal Request (0x05)
 ASC:                    0x26
 ASCQ:                   0x00
 Additional data:        0x00000000000000000000000000000000

but version 1.0.9 and 1.1.0 displays:

Sense Code:              Illegal Request (0x)
 ASC:                    0x&
 ASCQ:                   0x
 Additional data:        0x

The reason for this are changes made in aa22443
The old code uses HEX() macro

stenc/src/scsiencrypt.h

Lines 39 to 40 in 844306d

    
           #define HEX(x)                                                                 \ 
        
             right << setw(2) << setfill('0') << hex << (int)(x) << setfill(' ')

it cast to the appropriate type (int), but a new code doesn't do it. e.g:
old:
cerr<<" (0x"<<HEX(sd->senseKey)<<")"<<endl;
new:
std::cerr<<" (0x"<<std::hex << (sd->senseKey);
it should be std::cerr<<" (0x"<<std::hex << int(sd->senseKey); or std::cerr<<" (0x"<<std::hex << static_cast<int>(sd->senseKey);
At least 7 lines of code are affected.
PS.
The macro also formats in the right way e.g. displays 0x01 not 0x1

rewrite logging

Logging should be done through syslog(3) functions so the local sysadmin can keep /var/log tidy as their needs require. stenc should not just open files in /var/log and write to them.

stenc should detect an empty LTO drive and return a proper exit code

When running stenc on a drive with not cartridge, it "waits" doing nothing.

Expected behavior:
stenc should detect an empty drive and return a proper exit code.

Workflow to run catch offline

@jmwilson How should a workflow look like (with the exact commands) to run the catch test framework offline?

stenc + CentOS 7.3, 7.4 and 7.5: Sense Code: Illegal Request (0x05) on LTO drive (encryption)

Under CentOS 7.3 to 7.5 stenc returns the following error:

$ stenc -f /dev/nst0 -a 1 -e on -k test.key
Provided key length is 256 bits.
Key checksum is 7a43.
Turning on encryption on device '/dev/nst0'...
Sense Code: Illegal Request (0x05)
ASC: 0x26
ASCQ: 0x00
Additional data: 0x00000000000000000000000000000000
Error: Turning encryption on for '/dev/nst0' failed!
Usage: stenc --version | -g -k [-kd ] | -f [--detail] [-e <on/mixed/rawread/off> [-k ] [-kd ] [-a ] [--protect | --unprotect] [--ckod] ]
Type 'man stenc' for more information.

Adding the line: memset(&kad,0,sizeof(kad)); in scsiencrypt.cpp fix this issue as described here:

What could cause a 'sense error' when setting LTO encryption?
https://serverfault.com/questions/864580/what-could-cause-a-sense-error-when-setting-lto-encryption

Patch for stenc v1.0.7 (https://github.com/scsitape/stenc/archive/1.0.7.tar.gz):

--- src/scsiencrypt.cpp	2018-08-29 03:48:57.815019821 +0000
+++ src/scsiencrypt.fixed.cpp	2018-08-29 03:49:36.303018034 +0000
@@ -250,6 +250,7 @@
 	//create the key descriptor
 	if(eOptions->keyName!=""){
 		SSP_KAD kad;
+		memset(&kad,0,sizeof(kad));
 		kad.type=0x00;
 		kad.authenticated=0;
 		//set the descriptor length to the length of the keyName

Patch: scsiencrypt.cpp.patch.txt

Thanks to lan and Kasperd for the solution.

Header of manpage is missing

The first lines render as

()                                                                                                                                                                                                                                                   ()

NAME
       stenc - SCSI Tape Hardware Encryption Manager

But there should be something like


STENC(1)                    General Commands Manual                   STENC(1)

NAME
       stenc - SCSI Tape Hardware Encryption Manager

MacOS version

Hello, is there a chance to run this tool on MacOS?

LTO-9 density code not mapped

My HP LTO-9 drive has a density code of 0x60 when a standard LTO-9 tape is inserted, but no translation shows up as the text. It should state "LTO-9"

Compilation error after merge PR91

OS: Fedora 36 x86_64
g++ --version
g++ (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)

$ LANG=C make
make all-recursive
make[1]: Entering directory '/home/pawel/stenc'
Making all in src
make[2]: Entering directory '/home/pawel/stenc/src'
depbase=echo main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||';
g++ -DHAVE_CONFIG_H -I. -I.. -std=c++17 -g -O2 -MT main.o -MD -MP -MF $depbase.Tpo -c -o main.o main.cpp &&
mv -f $depbase.Tpo $depbase.Po
main.cpp: In function 'int main(int, char**)':
main.cpp:407:30: error: 'numeric_limits' is not a member of 'std'
407 | conv_result > std::numeric_limits<
| ^~~~~~~~~~~~~~
main.cpp:408:66: error: expected primary-expression before '>' token
408 | decltype(algorithm_index)::value_type>::max()) {
| ^
main.cpp:408:69: error: '::max' has not been declared; did you mean 'std::max'?
408 | decltype(algorithm_index)::value_type>::max()) {
| ^~~
| std::max
In file included from /usr/include/c++/12/algorithm:61,
from main.cpp:18:
/usr/include/c++/12/bits/stl_algo.h:5756:5: note: 'std::max' declared here
5756 | max(initializer_list<_Tp> __l, _Compare __comp)
| ^~~
make[2]: *** [Makefile:370: main.o] Error 1
make[2]: Leaving directory '/home/pawel/stenc/src'
make[1]: *** [Makefile:361: all-recursive] Error 1
make[1]: Leaving directory '/home/pawel/stenc'
make: *** [Makefile:302: all] Error 2

Running stenc --detail shows Volume Encryption = Unable to determine?

Recently got a new tape library, using stenc 1.0.7 on AIX to enable tape encryption.

stenc -f /dev/rmt0 -e on -k /etc/tape/tape.key -a 1
Provided key length is 256 bits.
Key checksum is cc99.
Turning on encryption on device '/dev/rmt0.1'...
Success! See '/var/log/stenc' for a key change audit log.

stenc -f /dev/rmt0 --detail
Status for /dev/rmt0.1
--------------------------------------------------
Device Mfg:              IBM
Product ID:              ULT3580-HH8
Product Revision:        N4Q1
Drive Encryption:        on
Drive Output:            Decrypting
                         Unencrypted data not outputted
Drive Input:             Encrypting
Key Instance Counter:    3
Encryption Algorithm:    1
Drive Key Desc.(uKAD):   tape_key
Volume Encryption:       Unable to determine
Volume Algorithm:        1

Drive encryption shows on, however volume encryption returns "Unable to determine", I am a bit concerned.

Is it safe to write/read encrypted tapes with this sort of status?

ascii demo/screen cast

Demonstrate the look and feel of the tool in short examples.
https://asciinema.org/? Gif?

Consider compiling the man page from markdown and friends

The man page is very useful and well written.
However it is difficult to maintain. We have a PR claiming there would be a typo (I do not think this is true).

What do you think about a conversion to something like markdown and convert it with pandoc as described on https://www.howtogeek.com/682871/how-to-create-a-man-page-on-linux/
This way it is easy to maintain and we get also a nice man/pdf/html/whatever output at once.

Any objections or ideas about the man page, @ninthclowd?

Unable to activate mixed mode ecryption

I try to implement stenc for bacula, in particular on a LTO6 unit and it seems this option is not compatible. Could be this true?

Ubuntu Server 18.04.2, stenc 1.0.7-2

stenc -f /dev/nst0 -e mixed -k /etc/bacula/myaes.key -a 1 --ckod
Provided key length is 256 bits.
Key checksum is ffffcad2.
Turning on encryption on device '/dev/nst0'...
Sense Code:              Illegal Request (0x05)
 ASC:                    0x26
 ASCQ:                   0x00
 Additional data:        0x00000e00202020202020201500005881b9000097f0b982b5504c3
60000000000000000000000000000000000000000000000000000000000000000000000000000000
00045573233584d3250314100000000000000000000
Error: Turning encryption on for '/dev/nst0' failed!
Usage: stenc --version | -g <length> -k <file> [-kd <description>] | -f <device> 
[--detail] [-e <on/mixed/rawread/off> [-k <file>] [-kd <description>] [-a <index>] 
[--protect | --unprotect] [--ckod] ]
Type 'man stenc' for more information.
root@mxmexbkp01:/etc/bacula/scripts# Error: Turning encryption on for '/dev/nst0 
' failed!
Error:: command not found

Drop support for AIX?

None of the maintainers have access to an AIX build environment and there doesn't appear to be a turnkey low-cost way to get a hosted VM. Without knowing even the available compiler, there's no way to plan around the language standard to use, and whether the code even compiles.

Blank tape

I've tested the latest version (f5856d7) and it throws an error when an blank tape is in the drive.

Old behavior:

# stenc -f /dev/nst1 --detail
Status for /dev/nst1
--------------------------------------------------
Device Mfg:              HP      
Product ID:              Ultrium 4-SCSI  
Product Revision:        U64D
Drive Encryption:        off
Drive Output:            Not decrypting
                         Raw encrypted data not outputted
Drive Input:             Not encrypting
Key Instance Counter:    0

New old behavior:

# stenc -f /dev/nst1 --detail
Status for /dev/nst1
--------------------------------------------------
Vendor:                  HP      
Product ID:              Ultrium 4-SCSI  
Product Revision:        U64D
Drive Encryption:        off
Drive Output:            Not decrypting
                         Raw encrypted data not outputted
Drive Input:             Not encrypting
Key Instance Counter:    0
Sense Code:              Blank tape (0x08)
 ASC:                    0x14
 ASCQ:                   0x03
 Additional data:        0x00000000000000000000000000000000

LGTM CI Checks fail without AC_CHECK_INCLUDES_DEFAULT

LGTM seems to need a fix, if AC_CHECK_INCLUDES_DEFAULT is not active.
The macro was dropped due to #33

Run autoreconf -i
  autoreconf -i
  shell: /usr/bin/bash -e {0}
configure.ac:18: error: possibly undefined macro: AC_CHECK_INCLUDES_DEFAULT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
Error: Process completed with exit code 1.

stenc: Package for Red Hat / CentOS / Fedora

stenc should be included in Red Hat / CentOS / Fedora

Red Hat: The code path - How does new code enter Red Hat products?
https://www.redhat.com/en/blog/code-path-how-does-new-code-enter-red-hat-products

Fedora project: Package Review Process
https://fedoraproject.org/wiki/Package_Review_Process

CI needs pandoc

Any ideas how to fix our CI?

Perhaps this can help us:
https://github.com/pandoc/pandoc-action-example

Error when compiling for freeBSD

I'm wondering if you might have advice on getting stenc to compile on freeBSD. I created a new jail in 13.1, installed automake and I get this error:

# autoreconf --install 
configure. ac: 15: warning: The preprocessor macro SIDC_ HEADERS' is obsolete.
configure.ac: 15: Except in unusual embedded environments, you can safely include all 
configure.ac: 15: ISO C90 headers unconditionally.
configure.ac:80: error: possibly undefined macro: AC_MSG_NOTICE
If this token and others are legitimate, please use m4 _pattern allow.
See the Autoconf documentation.
configure.ac:81: error: possibly undefined macro: AC SUBST autoreconf2.71: error: /usr/local/bin/autoconf2.71 failed with exit status: 1

	#define HEX(x) \
	right << setw(2) << setfill('0') << hex << (int)(x) << setfill(' ')

scsitape / stenc Goto Github PK

stenc's Introduction

Stenc

Features

Get the source code and compile

Usage example

Linux Packages

Requirements

License

Further reading

stenc's People

Contributors

Stargazers

Watchers

Forkers

stenc's Issues

Recommend Projects

Recommend Topics

Recommend Org