From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8F7FC433EF for ; Sat, 30 Oct 2021 10:08:33 +0000 (UTC) Received: from mail.server123.net (mail.server123.net [78.46.64.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1E63A6103E for ; Sat, 30 Oct 2021 10:08:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1E63A6103E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=saout.de X-Virus-Scanned: amavisd-new at saout.de Authentication-Results: mail.server123.net (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::531; helo=mail-ed1-x531.google.com; envelope-from=gmazyland@gmail.com; receiver= Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sat, 30 Oct 2021 12:06:11 +0200 (CEST) Received: by mail-ed1-x531.google.com with SMTP id w15so47208738edc.9 for ; Sat, 30 Oct 2021 03:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=LXqaQt7v8uWZJ7mTYUqcvsOHDuZ1HwOM1kGMdN1d0Uc=; b=oxFubybbXjskihV/lFIvpU+COU59ftcA5N/xeEaYKeTfS2z1VvCmzwRBqTvD0Qmvtt zmw40veMH2IpFBOBeMXFBmSvbQpkNUJO3mW1bz7qBvXMzbuqHPBv3N9BX6BVC42PUYPP kCWE+z1irp/A7B7rj4g/dA6gElt+dF4q3gx5FHPoFauL4R+W3jmn7JqT97BVoLOoxC1F CdBHjwZv90Z99+47u2XnS/f+7yQeEkXZJlQYedSoSnN7bRQiSyaDQ/H2qb/8YrIheYWk Hjdwny5nK7Q7ypyA4ulTlwK1pE3UHXiu23yoEKe4I+OAowwn062LZl8WBbIaHqZhDE5j 43lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=LXqaQt7v8uWZJ7mTYUqcvsOHDuZ1HwOM1kGMdN1d0Uc=; b=jEYoeVmy4hMOgIcKowea0c/upNhM3F5d9X6Ht1FU9OHP0kBTQKlZO4qJzgmri/sYju smgysNt1qW3T+OyHs2Fd2fVDcl1xNMqUXYkQ46rnsr24XQf6niQfSmrTCoWyQvC3HVB3 zyiT7wdy9WWUdFCGp95Q3O/BbGkejXM1OVfdVYVjiEwgSH5BdZ1gOJqAXews/LJjLzTd QE6gs7zgwc7LZSuKeQMMKgrKf5Ua1W6XGWq4GgsjDc3qXLh48X2OFcaYvnijJwUv9Sxj C68v0EEJ8aLzSgQuW3buAaYP3BI0FBeDX7PcxyGh73wdD1oHIXbBtvlBl/92IRg0fRkU sp2Q== X-Gm-Message-State: AOAM530QysoLDEoApNVhPKBn4bK1RaYUOmg4Ga5G5CgGdHounpdTlGab m3ezWewRzbtm2ASvHqW9h/I= X-Google-Smtp-Source: ABdhPJxGTuaiTKqS0MT/8JZt0M117s96yKU886lxnaVSl/HUxGdEF9EpnmJF6fn418RQFLmimOrZ/A== X-Received: by 2002:aa7:d2cc:: with SMTP id k12mr19323997edr.243.1635588370607; Sat, 30 Oct 2021 03:06:10 -0700 (PDT) Received: from [192.168.8.101] (89-24-48-156.nat.epc.tmcz.cz. [89.24.48.156]) by smtp.gmail.com with ESMTPSA id n10sm4062042ejk.86.2021.10.30.03.06.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Oct 2021 03:06:09 -0700 (PDT) Message-ID: <595a3a55-67be-f3fe-23bc-e1d71855a8fe@gmail.com> Date: Sat, 30 Oct 2021 12:06:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Phil Sutter References: <20211027232933.7445-1-phil@nwl.cc> <08f502bf-d41a-6b6a-36f7-60b4bddc1497@gmail.com> <20211029213117.GY1668@orbyte.nwl.cc> From: Milan Broz In-Reply-To: <20211029213117.GY1668@orbyte.nwl.cc> Message-ID-Hash: PW2FEE4HTUVRWOVYCODWV2WDXRJKKFKY X-Message-ID-Hash: PW2FEE4HTUVRWOVYCODWV2WDXRJKKFKY X-MailFrom: gmazyland@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: dm-crypt@saout.de, Vojtech Trefny X-Mailman-Version: 3.3.2 Precedence: list Subject: [dm-crypt] Re: [cryptsetup PATCH] Make BitLocker support optional List-Id: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit On 29/10/2021 23:31, Phil Sutter wrote: > Hi Milan, > > On Thu, Oct 28, 2021 at 09:14:10AM +0200, Milan Broz wrote: >> Support for all formats is mandatory (the pain to support various kernel configuration is already enough), >> so sorry, but I will not accept this patch. > > I can relate but in this case the default is enabled so unless someone > really cares nothing changes. All formats in libcryptsetup are intentionally always available. This was my intention since the beginning I started to add external format support (loopaes, truecrypt etc). ... >> What issues this solves have here? Why you cannot link it? > > On an embedded device with uClibc I need libiconv which is 1.4MB in > size. I was hoping to avoid having to ship this rather large library. > While it's awesome that cryptsetup now supports bitlk partitions, I > don't think it will see much use on embedded devices (e.g. a small file > server). So the whole problem is just to save 1.4M? I thought you cannot compile it at all. Then this is not really something what I think is really important - cryptsetup is not indented to be used in super-small embedded devices. (But yes, we try to avoid big libraries dependences. But bitlk support is mandatory function now.) You can always add own patches obviously, it is OSS, but this is not going to be merged upstream. >> We use only some specific functions so the solution can be just to implement this internally. > > Converting passphrases to utf16 is mandatory for bitlk support, right? Not only passphrases, labels etc are stored in utf16. But it is only small subset of iconv we need. > In general, I'm not sure if all this is feasible - libcryptsetup is > already 1.9MB and maintaining a mini-iconv is error-prone and likely to > remain mostly untested. Systemd implements own utf functions (not sure why). I would better add similar to libcryptsetup just for bitlk format (with unit test), but not sure it is worth to spend time here... (IOW remove iconv dependence completely.) (Anyway, cc to Vojta, who wrote this code.) Milan _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de