VOGONS

Common searches


What to do when Windows 7 support ends in a few weeks time?

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 200 of 317, by gerwin

User metadata
Rank l33t
Rank
l33t

Parallel to Windows 7, Small Business Server 2011 support is ending on the exact same day. Here is what the usual ICT services in our area offer, translated to english.

- migrate the existing server operating system to Windows Server 2016 or 2019. This can often also lead to the hardware being replaced or upgraded.
- another option is to migrate from the server (s) to the cloud. A BPA cloud solution is very suitable for this. With BPA Cloud, employees always have access to the corporate network.
- the third option is to migrate the files to a Microsoft Office 365 online server.

Local Exchange email is replaced by cloud services in any case, admitted it wasn't easy to manage for a small office. I read some complaints that Windows Server 2019 backs-up to the cloud, instead of locally. All that makes the choice like "half-cloud" versus "mostly cloud" versus "full cloud". Asking "What else is there?" got us the reply that there are actually more options, but those options are only interesting for larger organisations (100+).

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 201 of 317, by Scali

User metadata
Rank l33t
Rank
l33t
gdjacobs wrote:

Why would they need a shared certificate?

They don't specifically *need* one, but it would be most practical, seeing as they also share a lot of code.
Most linux distributions use the same bootloader, so why not just sign it once? Why would every linux distro need to build the bootloader themselves and sign it themselves?

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 202 of 317, by SirNickity

User metadata
Rank Oldbie
Rank
Oldbie

The concept that "the Linux community" could sign a bootloader doesn't seem reasonable to me, and this is a central issue I take with this design. Certificates are basically a "proof of origin" that aligns rather poorly with an ecosystem that is, by its very nature, decentralized. Red Hat could have a certificate. GNU probably could. Maybe all the distros could, individually. But since nobody really owns the source code, and it's problematic to assume anyone owns the binaries as well, signing binaries is just not a sensible approach.

As a Gentoo user, the only binaries I get from my distro are the ones used to boot the live CD for installation. I can then choose to either proceed with a base OS underlay, precompiled (a "stage 3" install), or start from scratch and generate every byte of executable code starting with the C libraries, build system, etc. Either way, GRUB is not delivered as a precompiled package, it's delivered as source. So I would have to be able to sign the resulting binary with "Linux's" key, or go to all the trouble of standing up my own self-signed PKI and exporting that to the UEFI keychain. It's not impossible, so long as the UEFI implementation continues to allow importing new keys, but what am I getting from this?

I really take no issue with UEFI shipping with a handful of root certificates, and identifying the vendor of signed boot loaders through delegation -- ala SSL. I don't necessarily take issue with having, as someone else put it, a mandated spec enforcing the OPTION to refuse to boot unsigned code. I'm also not against the option of requesting the user to authorize booting code that is not signed by a known certificate chain, and then automatically importing its certificate (even self-signed!) and then, on future boots, verifying that certificate has not changed. That would accomplish every bit of the "anti-tampering" goal, and proivide all the claimed benefits the FSF did acknowledge, without taking the authority away from end users.

And, yes, it's very similar to what happens today. Similar, but not exactly the same. The emphasis of today's scheme is the default behavior, and the ambiguity over the future direction of the technology. You chalk up the "there are no guarantees" thing to an apples-to-oranges comparison to life in general, but the reality is, yes there certainly are guarantees. Specifications, roadmaps, and charters, for example. That's not to say nobody has ever broken those promises, but at least there's a good-faith effort to dictate how it will and will not be used to affect choice and market strategies.

I lost all trust in Microsoft when BeOS and Linux both got kicked out of the OEM market because Microsoft strong-armed vendors into staying loyal to Microsoft. The Windows license required using the Window boot loader to remain compliant. The boot loader could not legally (and not even technically, without resorting to shenanigans) be used to boot other OSes. Ergo, the only OS that can be installed is Windows. I do not trust them.

Reply 204 of 317, by appiah4

User metadata
Rank l33t++
Rank
l33t++
Scali wrote:

Some people just think that the world will adapt to whatever ideas and beliefs they have.
These people should be prepared to deal with disappointment.

Yes, they should immediately resign to fate and submit to their corporate overlords. 😵

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 205 of 317, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Scali wrote:

Most linux distributions use the same bootloader, so why not just sign it once? Why would every linux distro need to build the bootloader themselves and sign it themselves?

Even if a source tree makes reproducible builds, most Linux distributions won't have a matching binary signature for the bootloader as each has their own build infrastructure and may use a different release version as well.

All hail the Great Capacitor Brand Finder

Reply 207 of 317, by Scali

User metadata
Rank l33t
Rank
l33t
gdjacobs wrote:

Even if a source tree makes reproducible builds, most Linux distributions won't have a matching binary signature for the bootloader as each has their own build infrastructure and may use a different release version as well.

As I tried to say in my previous post: Then they should stop doing that, because that's clearly not how the world works!
They can compile and sign their own binaries all they want. Secure Boot *only* cares about the bootloader. What would be the big deal against using a standardized binary for all linux distros?
It's just a tiny shim that loads the initial bootstrapper for your OS. So even if you want to make modifications to the boot process, there's really no reason to modify the bootloader itself, you just move that into your own bootstrapper.

As Linus Torvalds tried to say, people are making a big deal out of nothing.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 208 of 317, by 386SX

User metadata
Rank l33t
Rank
l33t

So I understand that Secure Boot may not be (or be) a problem even if indeed sounds like one way (maybe was the only on the table) to solve such security problem that depends of which is point of view or who has the "strongest" point of view while both may sound correct.
But beside that, if security became such a discussion in the industry to change the whole bios standard, what would have been the point of all the other 'features' that basically make it a sort of "o.s. itself" considering (I suppose) a big amount of code/files/libraries/drivers considering the modern bios size, and as above with also a full tcp/ip stack, remote connection features to update the bios itself from the bios itself or remote access to the bios from your other devices I can imagine for better office administration ict infastructure, also maybe warranty checking or whatever...should those logics have been considered a more serious manufacturers or user concern for their products theorical security and, as was saying its lifetime, when the bios will not be updated anymore? Because at that point some may ask himself if lifetime may have been or not at first "a possible opposite concern" to make the next new product to stay updated and so on, that's somehow what some cheaper mobile phone logic seems to have already.
If a bios become a sort of o.s. itself that's so complex may need many more updates what's the point to put security in such priority with smart logics the o.s. booting while the bios itself may become in the future a more serious source of problems?
It sounds like a dog following his tail while the obvious solution would have been the simpler where usually 'the less' (code, features, etc) may means the better.

Reply 209 of 317, by Jo22

User metadata
Rank l33t++
Rank
l33t++

^Good question, indeed. UEFI perhaps brings more complexity into the game than it is really worth. 😐
All the necessary base functionality was added to conventional BIOS over the years before (USB and network boot, firmware update from within BIOS itself etc).
Even workarounds for the MBR limits were manageable as Linux demonstrated (could boot off GPT partitions on BIOS systems).

In some way or another, UEFI reminds me of a modern rootkit or an oldschool boot sector virus / memory resident virus (TSR like) from the DOS times.
It can do anything it wishes without letting the actual "OS" knowing what's truely going on behind.
This is in contrast to a conventional OS, which has a task manager, process viewer or boot logger you could check.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 210 of 317, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Scali wrote:
As I tried to say in my previous post: Then they should stop doing that, because that's clearly not how the world works! They ca […]
Show full quote
gdjacobs wrote:

Even if a source tree makes reproducible builds, most Linux distributions won't have a matching binary signature for the bootloader as each has their own build infrastructure and may use a different release version as well.

As I tried to say in my previous post: Then they should stop doing that, because that's clearly not how the world works!
They can compile and sign their own binaries all they want. Secure Boot *only* cares about the bootloader. What would be the big deal against using a standardized binary for all linux distros?
It's just a tiny shim that loads the initial bootstrapper for your OS. So even if you want to make modifications to the boot process, there's really no reason to modify the bootloader itself, you just move that into your own bootstrapper.

As Linus Torvalds tried to say, people are making a big deal out of nothing.

First, a magical golden binary is contrary to the various practical motivations of Free Software, OSS, etc. It's resistant to improvement, experimentation, and security review. Second, by allowing code signing to be disabled for kernel boot up, the system is again vulnerable to rootkit techniques rendering the whole exercise pointless. Why not mandate a mechanism to bypass secure boot or preload local keys instead? Even better, why not mandate a system of decentralized signing authority (as I suggested) so ISVs are not so heavily dependent on one player (be they a competitor or not) while deriving the benefit of a cryptographically validated bootstrap?

The community had a healthy amount of distrust of things coming out of Redmond due to previous experience, so the skepticism towards Secure Boot was somewhat understandable. Of course, that has nothing to do with the architectural problems of UEFI and related deficiencies of ACPI. I actually consider UEFI to be a huge step backwards from OFM/OpenBoot, for instance.

All hail the Great Capacitor Brand Finder

Reply 211 of 317, by 386SX

User metadata
Rank l33t
Rank
l33t
Jo22 wrote:
^Good question, indeed. UEFI perhaps brings more complexity into the game than it is really worth. :neutral: All the necessary […]
Show full quote

^Good question, indeed. UEFI perhaps brings more complexity into the game than it is really worth. 😐
All the necessary base functionality was added to conventional BIOS over the years before (USB and network boot, firmware update from within BIOS itself etc).
Even workarounds for the MBR limits were manageable as Linux demonstrated (could boot off GPT partitions on BIOS systems).

In some way or another, UEFI reminds me of a modern rootkit or an oldschool boot sector virus / memory resident virus (TSR like) from the DOS times.
It can do anything it wishes without letting the actual "OS" knowing what's truely going on behind.
This is in contrast to a conventional OS, which has a task manager, process viewer or boot logger you could check.

When I first heard/tried/read about the early versions in the netbooks time I didn't knew about this change but later reading newer mainboards bios "features" I couldn't help but think to those old ict admin environments when they were testing those internal server cards for reboot, debug or configure them by remote.
I know this is not obviously what these bios are for, but for what I can understand it's not like they wouldn't be (now) capable of, when before bios risks were probably mostly not possible. Bios may have been the last resisting component to a modernity of "products" that are slowly shifting to be "services" whatever you need it or not; older ones were basically making the whole system first of all an "offline" owned device and then eventually "online/services" oriented devices.
This would still make sense on my humble opinion nowdays: I'm not expert but I can't see how some/these "features" or even the possibility the bios concept itself could (now) introduce them at first, could be considered "safe" for a company workstation environment.
When changes were done, I can understand some were for the best in the user direction, let's think to the 386/486 enviroments with so many jumpers where you could easily burn the most expensive components in seconds and the "automatic" configuration since some of the Socket7 mainboards has been for the best; nowdays things are quite different.

Last edited by 386SX on 2019-11-09, 14:47. Edited 3 times in total.

Reply 212 of 317, by Scali

User metadata
Rank l33t
Rank
l33t
gdjacobs wrote:

First, a magical golden binary is contrary to the various practical motivations of Free Software, OSS, etc.

As I said, the world doesn't work that way.
Which makes them IMPRACTICAL motivations.

gdjacobs wrote:

It's resistant to improvement, experimentation, and security review.

You mean like the BIOS/UEFI itself? Basically you're just shifting things from entirely BIOS/UEFI to having a small shim loaded from your boot device.
Other than that, NOTHING changes.

gdjacobs wrote:

Second, by allowing code signing to be disabled for kernel boot up, the system is again vulnerable to rootkit techniques rendering the whole exercise pointless.

That's the choice you have: Either you support Secure Boot all the way, or you just use a shim to circumvent it because you want to recompile your code, and can't sign it in a way that can be booted directly.

gdjacobs wrote:

Why not mandate a mechanism to bypass secure boot or preload local keys instead?

Because the linux world is too small to mandate anything. They tried to boycott Secure Boot, that failed.
Mandating a mechanism to bypass it would fail just as hard.
Vendors may or may not include a mechamism to bypass Secure Boot. If you support Secure Boot all the way, it's a non-issue. If you don't, you have to be selective with the hardware you choose.
Preloading local keys was already explained in the Gentoo wiki page I linked to earlier. I believe that part actually is mandated.

gdjacobs wrote:

Even better, why not mandate a system of decentralized signing authority (as I suggested)

Because you're wrong? 😀
The certificates are already decentralized. But there are no common linux keys, and the distros that have their own key, generally are ignored by vendors because they're insignificant, so they don't get included in the firmware from the factory.
The system doesn't work in practice.

Which is why the practical solution exists where Microsoft will sign code for you.

gdjacobs wrote:

The community had a healthy amount of distrust of things coming out of Redmond due to previous experience

But there is nothing coming out of Redmond. UEFI and Secure Boot are not Microsoft's invention, and Microsoft is not a CA.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 213 of 317, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Scali wrote:

As I said, the world doesn't work that way.
Which makes them IMPRACTICAL motivations.

They're very practical, but yes, sometimes it's necessary to be pragmatic.

gdjacobs wrote:

It's resistant to improvement, experimentation, and security review.

Scali wrote:

You mean like the BIOS/UEFI itself?

Well, yes, although distros aren't responsible for that.

Scali wrote:
Because you're wrong? :) The certificates are already decentralized. But there are no common linux keys, and the distros that ha […]
Show full quote
gdjacobs wrote:

Even better, why not mandate a system of decentralized signing authority (as I suggested)

Because you're wrong? 😀
The certificates are already decentralized. But there are no common linux keys, and the distros that have their own key, generally are ignored by vendors because they're insignificant, so they don't get included in the firmware from the factory.
The system doesn't work in practice.

Which is why the practical solution exists where Microsoft will sign code for you.

I don't think you understand the meaning of the word 'decentralized'. That doesn't entail Microsoft, Intel, the hardware vendors, or any other small, select group being the gatekeeper of what gets authorized to load on a computer.

Scali wrote:
gdjacobs wrote:

The community had a healthy amount of distrust of things coming out of Redmond due to previous experience

But there is nothing coming out of Redmond. UEFI and Secure Boot are not Microsoft's invention, and Microsoft is not a CA.

Microsoft is a member of the UEFI Forum just as they've been heavily involved in ACPI.

All hail the Great Capacitor Brand Finder

Reply 214 of 317, by Scali

User metadata
Rank l33t
Rank
l33t
gdjacobs wrote:

They're very practical, but yes, sometimes it's necessary to be pragmatic.

The FSF is a highly idealistic organization, very impractical. There's a long history of clashes between the FSF and the real world, with technologies that your average consumer would take for granted, such as mp3 or TiVo.
You can't be idealistic and pragmatic at the same time.

gdjacobs wrote:

Well, yes, although distros aren't responsible for that.

And how is that not a problem, but some shared boot shim would be?
That's not very pragmatic, now is it?

gdjacobs wrote:

I don't think you understand the meaning of the word 'decentralized'.

No you!
Seriously, it *is* decentralized because companies can apply for signing certificates at a number of certificate authorities.

gdjacobs wrote:

That doesn't entail Microsoft, Intel, the hardware vendors, or any other small, select group being the gatekeeper of what gets authorized to load on a computer.

Neither Microsoft, Intel or any hardware vendor is a certificate authority. Which was the point I was making earlier, but for some reason it keeps going over your head.
Certificate authorities are independent organizations.

gdjacobs wrote:

Microsoft is a member of the UEFI Forum just as they've been heavily involved in ACPI.

Microsoft is just one of many members of the UEFI Forum, and Secure Boot did not originate from them.
EFI itself was developed by Intel, and Intel was also a big factor in developing Secure Boot (based on US govt demands for more security for the pre-boot environment, considering that UEFI is actually more vulnerable that more primitive environments), somewhere around 2010. Microsoft did not start using it until years later (and if govt requires it, it's pretty obvious that a company such as MS will support. They want to keep their govt contracts. So not exactly an evil ploy by MS to lock out other OSes. Rather a move by MS to prevent them from being locked out of the govt market due to insufficient security). Microsoft also mandated that on x86 systems, there must be a feature to disable Secure Boot.
Read this paper so you can get your history straight: https://uefi.org/sites/default/files/resource … utions_2019.pdf

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 215 of 317, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

Since the subject here is Windows 7, is there a way to install it through bootcamp on current macOS? Because bootcamp actually only allows me to install the annoying Windows 10.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 216 of 317, by JonathonWyble

User metadata
Rank Member
Rank
Member
bfcastello wrote:

Since the subject here is Windows 7, is there a way to install it through bootcamp on current macOS? Because bootcamp actually only allows me to install the annoying Windows 10.

By "Boot Camp", you mean this? https://en.wikipedia.org/wiki/Boot_Camp_(software)
If so, according to the article, you can install only the 64-bit version of Windows 7. It also seems you can only have new installations of the operating system on Boot Camp. So yeah, I think you can install Windows 7 from this so called Boot Camp (even though I've never of heard of that before).

1998 Pentium II build

1553292341.th.19547.gif

Reply 217 of 317, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
JonathonWyble wrote:
bfcastello wrote:

Since the subject here is Windows 7, is there a way to install it through bootcamp on current macOS? Because bootcamp actually only allows me to install the annoying Windows 10.

By "Boot Camp", you mean this? https://en.wikipedia.org/wiki/Boot_Camp_(software)
If so, according to the article, you can install only the 64-bit version of Windows 7. It also seems you can only have new installations of the operating system on Boot Camp. So yeah, I think you can install Windows 7 from this so called Boot Camp (even though I've never of heard of that before).

Yup, the boot camp assistant. I think it only lets me install the 10 even though this is the 2013 MBP.

EDIT: No dice. It still forces me to install Windows 10. I was going to try the BootCamp info.plist hack, I did it once for an unsupported iMac years ago, but starting with macOS Catalina, this $#*$#(! is read-only file system, even with SIP Disabled. Catalina has a new way of protecting system files.

I'll pretend to be Rhett Butler and just say: "Frankly, my dear, I don't give a damn." Fu$# this, I'm going the virtual machine route again.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!

Reply 218 of 317, by JonathonWyble

User metadata
Rank Member
Rank
Member
bfcastello wrote:

EDIT: No dice. It still forces me to install Windows 10. I was going to try the BootCamp info.plist hack, I did it once for an unsupported iMac years ago, but starting with macOS Catalina, this $#*$#(! is read-only file system, even with SIP Disabled. Catalina has a new way of protecting system files.

Huh, I don't get it. This article on Windows 7 in Boot Camp seems to explain how it can only handle the 64-bit version of 7. What MacOS version are you using? Because the article mentions the fact that it's been effective since the latest version of Mac OS X 10.8.3 (Mountain Lion).

1998 Pentium II build

1553292341.th.19547.gif

Reply 219 of 317, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
JonathonWyble wrote:
bfcastello wrote:

EDIT: No dice. It still forces me to install Windows 10. I was going to try the BootCamp info.plist hack, I did it once for an unsupported iMac years ago, but starting with macOS Catalina, this $#*$#(! is read-only file system, even with SIP Disabled. Catalina has a new way of protecting system files.

Huh, I don't get it. This article on Windows 7 in Boot Camp seems to explain how it can only handle the 64-bit version of 7. What MacOS version are you using? Because the article mentions the fact that it's been effective since the latest version of Mac OS X 10.8.3 (Mountain Lion).

macOS Catalina 10.15.1

I will just go ahead with a virtual machine.

EDIT: I have a Win10 VM and I am actually in the works of tweaking its privacy settings to stop the telemetry data and other annoyances. I heard about a WinTweaker or something like that in this thread? Anyone know where can I find it? Much appreciated

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
READ: Right to Repair sucks and is illegal!